honeymoose
/
angular-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
angular-cn/packages/compiler-cli/ngcc/test/host/util.ts

51 lines
2.3 KiB
TypeScript
Raw Normal View History

fix(ivy): never use imported type references as values (#29111) ngtsc occasionally converts a type reference (such as the type of a parameter in a constructor) to a value reference (argument to a directiveInject call). TypeScript has a bad habit of sometimes removing the import statement associated with this type reference, because it's a type only import when it initially looks at the file. A solution to this is to always add an import to refer to a type position value that's imported, and not rely on the existing import. PR Close #29111
2019-03-04 14:43:55 -05:00
/**
* @license
build: update license headers to reference Google LLC (#37205) Update the license headers throughout the repository to reference Google LLC rather than Google Inc, for the required license headers. PR Close #37205
2020-05-19 15:08:49 -04:00
* Copyright Google LLC All Rights Reserved.
fix(ivy): never use imported type references as values (#29111) ngtsc occasionally converts a type reference (such as the type of a parameter in a constructor) to a value reference (argument to a directiveInject call). TypeScript has a bad habit of sometimes removing the import statement associated with this type reference, because it's a type only import when it initially looks at the file. A solution to this is to always add an import to refer to a type position value that's imported, and not rely on the existing import. PR Close #29111
2019-03-04 14:43:55 -05:00
*
* Use of this source code is governed by an MIT-style license that can be
* found in the LICENSE file at https://angular.io/license
*/
import * as ts from 'typescript';
fix(compiler-cli): avoid creating value expressions for symbols from type-only imports (#37912) In TypeScript 3.8 support was added for type-only imports, which only brings in the symbol as a type, not their value. The Angular compiler did not yet take the type-only keyword into account when representing symbols in type positions as value expressions. The class metadata that the compiler emits would include the value expression for its parameter types, generating actual imports as necessary. For type-only imports this should not be done, as it introduces an actual import of the module that was originally just a type-only import. This commit lets the compiler deal with type-only imports specially, preventing a value expression from being created. Fixes #37900 PR Close #37912
2020-07-03 14:12:24 -04:00
import {CtorParameter, TypeValueReferenceKind} from '../../../src/ngtsc/reflection';
fix(ivy): never use imported type references as values (#29111) ngtsc occasionally converts a type reference (such as the type of a parameter in a constructor) to a value reference (argument to a directiveInject call). TypeScript has a bad habit of sometimes removing the import statement associated with this type reference, because it's a type only import when it initially looks at the file. A solution to this is to always add an import to refer to a type position value that's imported, and not rely on the existing import. PR Close #29111
2019-03-04 14:43:55 -05:00
/**
* Check that a given list of `CtorParameter`s has `typeValueReference`s of specific `ts.Identifier`
* names.
*/
export function expectTypeValueReferencesForParameters(
fix(ngcc): use aliased exported types correctly (#38666) If a type has been renamed when it was exported, we need to reference the external public alias name rather than the internal original name for the type. Otherwise we will try to import the type by its internal name, which is not publicly accessible. Fixes #38238 PR Close #38666
2020-09-01 11:49:48 -04:00
parameters: CtorParameter[], expectedParams: (string|null)[],
fromModule: (string|null)[] = []) {
style(ngcc): reformat of ngcc after clang update (#36447) PR Close #36447
2020-04-06 03:30:08 -04:00
parameters!.forEach((param, idx) => {
fix(ivy): never use imported type references as values (#29111) ngtsc occasionally converts a type reference (such as the type of a parameter in a constructor) to a value reference (argument to a directiveInject call). TypeScript has a bad habit of sometimes removing the import statement associated with this type reference, because it's a type only import when it initially looks at the file. A solution to this is to always add an import to refer to a type position value that's imported, and not rely on the existing import. PR Close #29111
2019-03-04 14:43:55 -05:00
const expected = expectedParams[idx];
if (expected !== null) {
fix(compiler-cli): avoid creating value expressions for symbols from type-only imports (#37912) In TypeScript 3.8 support was added for type-only imports, which only brings in the symbol as a type, not their value. The Angular compiler did not yet take the type-only keyword into account when representing symbols in type positions as value expressions. The class metadata that the compiler emits would include the value expression for its parameter types, generating actual imports as necessary. For type-only imports this should not be done, as it introduces an actual import of the module that was originally just a type-only import. This commit lets the compiler deal with type-only imports specially, preventing a value expression from being created. Fixes #37900 PR Close #37912
2020-07-03 14:12:24 -04:00
if (param.typeValueReference.kind === TypeValueReferenceKind.UNAVAILABLE) {
fix(ngcc): use aliased exported types correctly (#38666) If a type has been renamed when it was exported, we need to reference the external public alias name rather than the internal original name for the type. Otherwise we will try to import the type by its internal name, which is not publicly accessible. Fixes #38238 PR Close #38666
2020-09-01 11:49:48 -04:00
fail(`Incorrect typeValueReference generated for ${param.name}, expected "${
expected}" because "${param.typeValueReference.reason}"`);
fix(compiler-cli): avoid creating value expressions for symbols from type-only imports (#37912) In TypeScript 3.8 support was added for type-only imports, which only brings in the symbol as a type, not their value. The Angular compiler did not yet take the type-only keyword into account when representing symbols in type positions as value expressions. The class metadata that the compiler emits would include the value expression for its parameter types, generating actual imports as necessary. For type-only imports this should not be done, as it introduces an actual import of the module that was originally just a type-only import. This commit lets the compiler deal with type-only imports specially, preventing a value expression from being created. Fixes #37900 PR Close #37912
2020-07-03 14:12:24 -04:00
} else if (
fix(ngcc): use aliased exported types correctly (#38666) If a type has been renamed when it was exported, we need to reference the external public alias name rather than the internal original name for the type. Otherwise we will try to import the type by its internal name, which is not publicly accessible. Fixes #38238 PR Close #38666
2020-09-01 11:49:48 -04:00
param.typeValueReference.kind === TypeValueReferenceKind.LOCAL &&
fromModule[idx] != null) {
fail(`Incorrect typeValueReference generated for ${param.name}, expected non-LOCAL (from ${
fromModule[idx]}) but was marked LOCAL`);
fix(compiler-cli): avoid creating value expressions for symbols from type-only imports (#37912) In TypeScript 3.8 support was added for type-only imports, which only brings in the symbol as a type, not their value. The Angular compiler did not yet take the type-only keyword into account when representing symbols in type positions as value expressions. The class metadata that the compiler emits would include the value expression for its parameter types, generating actual imports as necessary. For type-only imports this should not be done, as it introduces an actual import of the module that was originally just a type-only import. This commit lets the compiler deal with type-only imports specially, preventing a value expression from being created. Fixes #37900 PR Close #37912
2020-07-03 14:12:24 -04:00
} else if (
fix(ngcc): use aliased exported types correctly (#38666) If a type has been renamed when it was exported, we need to reference the external public alias name rather than the internal original name for the type. Otherwise we will try to import the type by its internal name, which is not publicly accessible. Fixes #38238 PR Close #38666
2020-09-01 11:49:48 -04:00
param.typeValueReference.kind !== TypeValueReferenceKind.LOCAL &&
fromModule[idx] == null) {
fail(`Incorrect typeValueReference generated for ${
param.name}, expected LOCAL but was imported from ${
param.typeValueReference.moduleName}`);
fix(compiler-cli): avoid creating value expressions for symbols from type-only imports (#37912) In TypeScript 3.8 support was added for type-only imports, which only brings in the symbol as a type, not their value. The Angular compiler did not yet take the type-only keyword into account when representing symbols in type positions as value expressions. The class metadata that the compiler emits would include the value expression for its parameter types, generating actual imports as necessary. For type-only imports this should not be done, as it introduces an actual import of the module that was originally just a type-only import. This commit lets the compiler deal with type-only imports specially, preventing a value expression from being created. Fixes #37900 PR Close #37912
2020-07-03 14:12:24 -04:00
} else if (param.typeValueReference.kind === TypeValueReferenceKind.LOCAL) {
fix(ngcc): use aliased exported types correctly (#38666) If a type has been renamed when it was exported, we need to reference the external public alias name rather than the internal original name for the type. Otherwise we will try to import the type by its internal name, which is not publicly accessible. Fixes #38238 PR Close #38666
2020-09-01 11:49:48 -04:00
if (!ts.isIdentifier(param.typeValueReference.expression) &&
!ts.isPropertyAccessExpression(param.typeValueReference.expression)) {
fail(`Incorrect typeValueReference generated for ${
param.name}, expected an identifier but got "${
param.typeValueReference.expression.getText()}"`);
fix(ngcc): properly detect origin of constructor param types (#33901) The ReflectionHost supports enumeration of constructor parameters, and one piece of information it returns describes the origin of the parameter's type. Parameter types come in two flavors: local (the type is not imported from anywhere) or non-local (the type comes via an import). ngcc incorrectly classified all type parameters as 'local', because in the source files that ngcc processes the type parameter is a real ts.Identifer. However, that identifier may still have come from an import and thus might be non-local. This commit changes ngcc's ReflectionHost(s) to properly recognize and report these non-local type references. Fixes #33677 PR Close #33901
2019-11-18 14:53:25 -05:00
} else {
fix(ngcc): use aliased exported types correctly (#38666) If a type has been renamed when it was exported, we need to reference the external public alias name rather than the internal original name for the type. Otherwise we will try to import the type by its internal name, which is not publicly accessible. Fixes #38238 PR Close #38666
2020-09-01 11:49:48 -04:00
expect(param.typeValueReference.expression.getText()).toEqual(expected);
fix(ngcc): properly detect origin of constructor param types (#33901) The ReflectionHost supports enumeration of constructor parameters, and one piece of information it returns describes the origin of the parameter's type. Parameter types come in two flavors: local (the type is not imported from anywhere) or non-local (the type comes via an import). ngcc incorrectly classified all type parameters as 'local', because in the source files that ngcc processes the type parameter is a real ts.Identifer. However, that identifier may still have come from an import and thus might be non-local. This commit changes ngcc's ReflectionHost(s) to properly recognize and report these non-local type references. Fixes #33677 PR Close #33901
2019-11-18 14:53:25 -05:00
}
fix(compiler-cli): avoid creating value expressions for symbols from type-only imports (#37912) In TypeScript 3.8 support was added for type-only imports, which only brings in the symbol as a type, not their value. The Angular compiler did not yet take the type-only keyword into account when representing symbols in type positions as value expressions. The class metadata that the compiler emits would include the value expression for its parameter types, generating actual imports as necessary. For type-only imports this should not be done, as it introduces an actual import of the module that was originally just a type-only import. This commit lets the compiler deal with type-only imports specially, preventing a value expression from being created. Fixes #37900 PR Close #37912
2020-07-03 14:12:24 -04:00
} else if (param.typeValueReference.kind === TypeValueReferenceKind.IMPORTED) {
fix(ngcc): use aliased exported types correctly (#38666) If a type has been renamed when it was exported, we need to reference the external public alias name rather than the internal original name for the type. Otherwise we will try to import the type by its internal name, which is not publicly accessible. Fixes #38238 PR Close #38666
2020-09-01 11:49:48 -04:00
expect(param.typeValueReference.moduleName).toBe(fromModule[idx]!);
fix(compiler): handle type references to namespaced symbols correctly (#36106) When the compiler needs to convert a type reference to a value expression, it may encounter a type that refers to a namespaced symbol. Such namespaces need to be handled specially as there's various forms available. Consider a namespace named "ns": 1. One can refer to a namespace by itself: `ns`. A namespace is only allowed to be used in a type position if it has been merged with a class, but even if this is the case it may not be possible to convert that type into a value expression depending on the import form. More on this later (case a below) 2. One can refer to a type within the namespace: `ns.Foo`. An import needs to be generated to `ns`, from which the `Foo` property can then be read. 3. One can refer to a type in a nested namespace within `ns`: `ns.Foo.Bar` and possibly even deeper nested. The value representation is similar to case 2, but includes additional property accesses. The exact strategy of how to deal with these cases depends on the type of import used. There's two flavors available: a. A namespaced import like `import * as ns from 'ns';` that creates a local namespace that is irrelevant to the import that needs to be generated (as said import would be used instead of the original import). If the local namespace "ns" itself is referred to in a type position, it is invalid to convert it into a value expression. Some JavaScript libraries publish a value as default export using `export = MyClass;` syntax, however it is illegal to refer to that value using "ns". Consequently, such usage in a type position *must* be accompanied by an `@Inject` decorator to provide an explicit token. b. An explicit namespace declaration within a module, that can be imported using a named import like `import {ns} from 'ns';` where the "ns" module declares a namespace using `declare namespace ns {}`. In this case, it's the namespace itself that needs to be imported, after which any qualified references into the namespace are converted into property accesses. Before this change, support for namespaces in the type-to-value conversion was limited and only worked correctly for a single qualified name using a namespace import (case 2a). All other cases were either producing incorrect code or would crash the compiler (case 1a). Crashing the compiler is not desirable as it does not indicate where the issue is. Moreover, the result of a type-to-value conversion is irrelevant when an explicit injection token is provided using `@Inject`, so referring to a namespace in a type position (case 1) could still be valid. This commit introduces logic to the type-to-value conversion to be able to properly deal with all type references to namespaced symbols. Fixes #36006 Resolves FW-1995 PR Close #36106
2020-03-17 11:23:46 -04:00
expect(param.typeValueReference.importedName).toBe(expected);
fix(ivy): never use imported type references as values (#29111) ngtsc occasionally converts a type reference (such as the type of a parameter in a constructor) to a value reference (argument to a directiveInject call). TypeScript has a bad habit of sometimes removing the import statement associated with this type reference, because it's a type only import when it initially looks at the file. A solution to this is to always add an import to refer to a type position value that's imported, and not rely on the existing import. PR Close #29111
2019-03-04 14:43:55 -05:00
}
}
});
}