Since we generate a `.mjs` file as entry-point for jasmine tests,
a couple of issues prevented the transitive dependencies from
bootstrap targets to be brought in (causing resolution errors):
1. The `_files` (previously `_esm2015`) targets are no longer needed,
and they also miss all the information on runfiles.
2. The aspect for computing linker mappings does not respect the
`bootstrap` attribute from the `spec_entrypoint` so we manually
add the extract ESM output targets (this rule works with the aspect
and forwards linker mappings).
PR Close#48521
For every `ts_library` target we expose a shorthand that grants
access to the JS files because `DefaultInfo` of a ts library
only exposes the `.d.ts` files.
We rename this away from `es2015` since in practice it's a much
higher target these days. Additionally we no longer use the devmode
output but rather use the prodmode output which has the explicit
`.mjs` output- compatible with ESM.
PR Close#48521
This is the compile-time implementation of the `hostDirectives` feature plus a little bit of runtime code to illustrate how the newly-generated code will plug into the runtime. It works by creating a call to the new `ɵɵHostDirectivesFeature` feature whenever a directive has a `hostDirectives` field. Afterwards `ɵɵHostDirectivesFeature` will patch a new function onto the directive definition that will be invoked during directive matching.
For example, if we take the following definition:
```ts
@Directive({
hostDirectives: [HostA, {directive: HostB, inputs: ['input: alias']}]
})
class MyDir {}
```
Will compile to:
```js
MyDir.ɵdir = ɵɵdefineComponent({
features: [ɵɵHostDirectivesFeature([HostA, {
directive: HostB,
inputs: {
input: "alias"
}
}])]
});
```
The template type checking is implemented during directive matching by adding the host directives applied on the host to the array of matched directives whenever the host is matched in a template.
Relates to #8785.
PR Close#46868
In PR #45405, the Angular Package Format (APF) was updated so that
secondary entry-points (such as `@angular/common/http`) do not have
their own `package.json` file, as they used to. Instead, the paths to
their various formats and types are exposed via the primary
`package.json` file's `exports` property. As an example, see the v13
[@angular/common/http/package.json][1] and compare it with the v14
[@angular/common/package.json > exports][2].
Previously, `ngcc` was not able to analyze such v14+ entry-points and
would instead error as it considered such entry-points missing.
This commit addresses the issue by detecting this situation and
synthesizing a `package.json` file for the secondary entry-points based
on the `exports` property of the primary `package.json` file. This data
is only used by `ngcc` in order to determine that the entry-point does
not need further processing, since it is already in Ivy format.
[1]: https://unpkg.com/browse/@angular/common@13.3.5/http/package.json
[2]: https://unpkg.com/browse/@angular/common@14.0.0-next.15/package.json
PR Close#45833
Move the `loadPackageJson()` helper (and associated generic types, such
as `JsonObject`) from `packages/entry_point.ts` to `utils.ts` and also
rename it to `loadJson()`. This way, they can be used in other places in
future commits, without introducing cyclical dependencies.
PR Close#45833
The NodeJS Bazel linker does not work well on Windows because there
is no sandboxing and linker processes from different tests will attempt
to modify the same `node_modules`, causing concurrency race conditions
and resulting in flakiness.
PR Close#45872
Adds support for TypeScript 4.7. Changes include:
* Bumping the TS version as well as some Bazel dependencies to include https://github.com/bazelbuild/rules_nodejs/pull/3420.
* Adding a backwards-compatibility layer for calls to `updateTypeParameterDeclaration`.
* Making `LView` generic in order to make it easier to type the context based on the usage. Currently the context can be 4 different types which coupled with stricter type checking would required a lot of extra casting all over `core`.
* Fixing a bunch of miscellaneous type errors.
* Removing assertions of `ReferenceEntry.isDefinition` in a few of the language service tests. The field isn't returned by TS anymore and we weren't using it for anything.
* Resolving in error in the language service that was caused by TS attempting to parse HTML files when we try to open them. Previous TS was silently setting them as `ScriptKind.Unknown` and ignoring the errors, but now it throws. I've worked around it by setting them as `ScriptKind.JSX`.
PR Close#45749
This commit adds a type field to .d.ts metadata for directives, components,
and pipes which carries a boolean literal indicating whether the given type
is standalone or not. For backwards compatibility, this flag defaults to
`false`.
Tests are added to validate that standalone types coming from .d.ts files
can be correctly imported into new standalone components.
PR Close#45672
Proactively replaces our usages of the deprecated `ts.create*` methods in favor of using `ts.factory.create*` so that we're not surprised when the TS removes them in the future. Also accounts for some cases where the signature had changed.
PR Close#45134
Bundlers like Rollup may use an element access expression for an export
declaration, which causes ngcc to ignore those export declarations possibly
resulting in incomplete processing of packages.
Element access syntax may be used when the declared name is not considered
as valid JS identifier, but bundlers may be conservative in determining whether
an identifier can be used (to emit a property access) and opt for a string
literal in an element access instead.
The element access syntax introduces a problem for ngcc, where it wouldn't
consider such export as class declaration, causing them to be skipped. The
ngtsc compiler is implemented with the assumption that all class declarations
use a `ts.Identifier` as name, whereas the element access is using a string
literal for the declared name. This makes it troublesome for ngcc to support
this syntax form in UMD bundles.
To work around the problem, this function transforms these access expressions
into regular property accesses. The source text is parsed to an AST to allow
finding the element accesses in a robust way, after which the affected text
ranges are replaced with property accesses in the original source text.
Closes#44037
PR Close#44669
To make our test output i.e. devmode output more aligned
with what we produce in the NPM packages, or to be more
aligned with what Angular applications will usually consume,
the devmode output is switched from ES5 to ES2015.
Additionally various tsconfigs (outside of Bazel) have been
updated to match with the other parts of the build. The rules
are:
ES2015 for test configurations, ES2020 for actual code that will
end up being shipped (this includes the IDE-only tsconfigs).
PR Close#44505
Now that ViewEngine libraries can no longer be created, the latest
TypeScript version that ngcc should be able to process is TypeScript 4.3,
i.e. the version of TypeScript that was supported in Angular 12.
However, ngcc's integration tests used the TypeScript version of the
workspace to create the JavaScript files from TypeScript sources on
demand. This introduces friction when upgrading the TypeScript version
within the workspace, as changes to TypeScript's emit format may affect
ngcc's ability to process it correctly.
The on demand creation of JavaScript files was convenient for authoring
tests, but it also helped to detect incompatibilities with newer
versions of TypeScript. Now that ngcc no longer has to process newer
versions of TypeScript, we want to pin the integration suite to use
JavaScript code as if it were compiled using TypeScript 4.3, i.e. a
version of TypeScript that is actually supported by ngcc.
This commit updates the integration test to inline all the generated
files directly in the tests, instead of compiling them on demand. This
was done by temporarily installing TypeScript 4.3 and using it to create
the `loadTestFiles` statement from the original TypeScript inputs.
An alternative could have been to install TypeScript 4.3 as an actual
dependency in the workspace and using that to continue compiling the
integration suite on demand, but this brings some overhead in package
installations (TypeScript is ~60MB) and the authoring aspect of ngcc
integration test is expected to diminish, now that ngcc's support is no
longer a moving target.
PR Close#44448
Previously, when processing UMD, ngcc assumed that the `exports`
argument of the CommonJS factory call (if present) would be the first
argument of the call. This is generally true for the supported UMD
formats, but can change if ngcc prepends more imports (and thus factory
arguments) while processing the module. This could lead to errors when
trying to collect dependencies of an already processed module.
(This was accidentally broken in #44245 (commit 2bc3522e16).)
This commit fixes it by not making any assumptions about the position of
an `exports` argument in the CommonJS factory call.
Fixes#44380
PR Close#44381
Adds support for TypeScript 4.5. Includes the following changes:
* Bumping the package versions.
* Fixing a few calls to `createExportSpecifier` and `createImportSpecifier` that require an extra parameter.
* Adding some missing methods to the TS compiler hosts.
* Fixing an issue in the TS mocks for the ngcc tests where a regex was too agressive and was trying to match a path like `/node_modules/@typescript/lib-es5`.
* Accounting for type-only import specifiers when reporting DI errors (see #43620).
Fixes#43620.
PR Close#44164
Previously, the mock packages created for `UmdDependencyHost`'s tests,
specified the entry-point as `esm2015`. This does not matter in tests,
since the packages are explicitly passed to the `UmdDependencyHost`
(while in reality the appropriate host would be determined based on the
name of the entry-point property - in this case, detecting the
entry-point as ES2015 and not UMD).
However, in order to avoid confusion, this commit updates the test
packages to use `main` (the default property used for the UMD format in
`package.json` files).
PR Close#44245
Previously, the ngcc `UmdReflectionHost` would throw a misleading error
when trying to collect dependencies of an invalidly formatted UMD
module. This happened because an error would be thrown while trying to
construct the error message for the actual error, by calling `getText()`
on certain TypeScript AST nodes. See
https://github.com/angular/angular/issues/44019#issuecomment-959954121
for a more in-depth explanation.
This commit ensures `getText()` can be safely called on TypeScript AST
nodes when collecting dependencies of UMD modules.
PR Close#44245
This commit utilizes the infrastructure added in the previous commit to
run more tests against more of the supported UMD formats. This shall
give us more confidence that all aspects of UMD processing work
correctly with the various formats.
PR Close#44245
Previously, several ngcc test suites used their own helper to generate
test UMD modules.
This commit switches to using the same helper for generating UMD modules
across test suites. This improves DRYness (ensuring changes/fixes to the
UMD format need only be applied once) and makes it easier to test
different UMD formats in all test suites.
PR Close#44245
Previously, ngcc could only handle UMD modules whose wrapper function
was implemented as a `ts.ConditionalExpression` (i.e. using a ternary
operator). This is the format emitted by popular bundlers, such as
Rollup.
This commit adds support for a different format, that uses `if/else`
statements, which is what is [emitted by Webpack][1].
[1]: https://webpack.js.org/configuration/output/#type-umdFixes#44019
PR Close#44245
Previously, ngcc could only handle UMD modules whose wrapper function
was implemented as a `ts.ConditionalExpression` (i.e. using a ternary
operator). This is the format emitted by popular bundlers, such as
Rollup. However, this failed to account for a different format, using
`if/else` statements, such as the one [emitted by Webpack][1].
This commit prepares ngcc for supporting different UMD wrapper function
formats by decoupling the operation of parsing the wrapper function body
to capture the various factory function calls and that of operating on
the factory function calls (for example, to read or update their
arguments). In a subsequent commit, this will be used to add support for
the Webpack format.
[1]: https://webpack.js.org/configuration/output/#type-umd
PR Close#44245
ngcc used to rewrite `PRE_R3` markers to become `POST_R3` in order to
switch the runtime implementation in `@angular/core` from View Engine to
Ivy. Now that `@angular/core` is published as native Ivy package and the
runtime switch code has been removed, there is no need for ngcc to
perform this transform anymore.
PR Close#43891
When executing, ngcc writes a lock-file that is used to coordinate multiple concurrent instances of ngcc.
Previously, this file was written at `node_modules/@angular/compiler-cli/ngcc`, or similar depending upon the bundling of the package.
But this causes problems for setups where `node_modules` package directories are expected to be read-only.
Now, the lock-file is written as `.ngcc_lock_file` into the top of the `node_modules`, which is an acceptable place to store transient files.
This change should help to unblock use of tools like pnpm and lerna, which can use symlinks to readonly package directories.
PR Close#44228
This commit adds additional information to encourage developers to contact
the author of View Engine libraries and ask them to update to partial Ivy.
Fixes#42308
PR Close#43996
In #43879, `UmdReflectionHost` was updated to deal with the new UMD
format used by Rollup, where the parenthesis is around the wrapper
function and not the wrapper function call.
For reference, this caused failures in the `ngcc-validation` repo
([example 1][1], [example 2][2]).
This commit updates `UmdRenderingFormatter` to also handle both UMD
formats. In order to validate the change, this commit also updates the
`UmdRenderingFormatter` tests to run against both UMD formats.
[1]: https://circleci.com/gh/angular/ngcc-validation/65916
[2]: https://circleci.com/gh/angular/ngcc-validation/65758
PR Close#43931
Recently rollup, used by ng-packagr, changed the position of parentheses
around its generated UMD wrapper functions.
This commit ensures that ngcc can handle both.
Fixes#43870
PR Close#43879
Ngcc relies on cluster for distributing work. The master controller
sends messages to the workers as soon as the worker becomes `online`.
The online event is sent as part of the NodeJS cluster logic itself.
This does not work well because technically `online` could emit before the
worker started listening (this seems to be case now with ESM as the
imports are loaded in a way where `online` emits too early; before the
worker actually listens for messages).
We fix this by explicitly notifying the master when the worker
is ready for retrieving IPC messages/or tasks. This is more safe
anyway as it's not clearly specified when `online` emits.
PR Close#43431
Switches the compiler-cli usage of `__filename` to `import.meta.url`
when ESM bundles are generated. Unfortunately we cannot start using
only `import.meta` yet as we still build and run all code in Angular
in CommonJS module output for devmode tests.
This commit also fixes various instances where a jasmine spy was applied on
a namespace export that will break with ES module (and the interop for
CommonJS output). We fix these spies by using a default import.
PR Close#43431
As outlined in the previous commit which enabled the `esModuleInterop`
TypeScript compiler option, we need to update all namespace imports
for `typescript` to default imports. This is needed to allow for
TypeScript to be imported at runtime from an ES module.
Similar changes are needed for modules like `semver` where the types incorrectly
suggest named exports that will not exist at runtime when imported from ESM.
This commit refactors all imports to match with the lint rule we have
configured in the previous commit. See the previous commit for more
details on why certain imports have been changed.
A special case are the imports to `@babel/core` and `@babel/types`. For
these a special interop is needed as both default imports, or named
imports break the other module format. e.g default imports would work
well for ESM, but it breaks for CJS. For CJS, the named imports would
only work, but in ESM, only the default export exist. We work around
this for now until the devmode is using ESM as well (which would be
consistent with prodmode and gives us more valuable test results). More
details on the interop can be found in the `babel_core.ts` files (two
interops are needed for both localize/or the compiler-cli).
PR Close#43431
ngcc currently dynamially loads the `Transformer` code. It does this
to avoid unnecessary parsing and loading of transformer-related code
if there is nothing to process (so-called noop case). Unfortunately
this dynamic require is not recognized by ESBuild. The import needs
to be discovered as otheriwse the transformer code would not be included
in the bundled package output of the CLI.
The ngcc code needs to use an async runtime import as it would work
in ES modules. This introduces async code into to the compililation
pipeline, breaking the `ngccMain` synchronous invocation feature.
To avoid this, we just move the dynamic require/async import to
the file top-level so that we do not break synchronous processing
which the CLI relies on. This has the downside of slowing-down
the noop case a little but I believe that should be mitigated
through bundling of ngcc anyway. In the future with full-ESM
we won't be able to get around this anyway (unless we remove the
sync variant of ngcc processing).
PR Close#43431
Prior to this commit ngcc stored its package configuration in JavaScript
objects, which caused the builtin `Object` members to be found as
package configuration. This would subsequently crash as their shape was
not as expected.
This commit moves away from using raw JavaScript objects in favor of a
Map. To code was refactored such that `PartiallyProcessedConfig` is
now a class.
Fixes#43570
PR Close#43589
Adds support for TypeScript 4.4. High-level overview of the changes made in this PR:
* Bumps the various packages to `typescript@4.4.2` and `tslib@2.3.0`.
* The `useUnknownInCatchVariables` compiler option has been disabled so that we don't have to cast error objects explicitly everywhere.
* TS now passes in a third argument to the `__spreadArray` call inside child class constructors. I had to update a couple of places in the runtime and ngcc to be able to pick up the calls correctly.
* TS now generates code like `(0, foo)(arg1, arg2)` for imported function calls. I had to update a few of our tests to account for it. See https://github.com/microsoft/TypeScript/pull/44624.
* Our `ngtsc` test setup calls the private `matchFiles` function from TS. I had to update our usage, because a new parameter was added.
* There was one place where we were setting the readonly `hasTrailingComma` property. I updated the usage to pass in the value when constructing the object instead.
* Some browser types were updated which meant that I had to resolve some trivial type errors.
* The downlevel decorators tranform was running into an issue where the Closure synthetic comments were being emitted twice. I've worked around it by recreating the class declaration node instead of cloning it.
PR Close#43281
In anticipation of the removal of the View Engine npm package output,
the integration tests of ngcc are switched to use @angular packages for
from npm. The version 12 packages are guaranteed to always be View
Engine format which makes them suitable to be processed in the ngcc
integration tests.
PR Close#43234
The previous default algorithm was `md5`, which is not compliant with FIPS.
The default is now set to `sha256`, which is compliant.
Fixes#42577
PR Close#42582
The ngcc configuration gets hashed to be used when caching
but it was hardcoded to use the `md5` algorithm, which is
not FIPS compliant.
Now the hash algorithm can be configured in the ngcc.config.js
file at the project level.
PR Close#42582
Switches the repository to TypeScript 4.3 and the latest
version of tslib. This involves updating the peer dependency
ranges on `typescript` for the compiler CLI and for the Bazel
package. Tests for new TypeScript features have been added to
ensure compatibility with Angular's ngtsc compiler.
PR Close#42022
The other similar interfaces were renamed in https://github.com/angular/angular/pull/41119,
but this one was left since it had existed before Ivy. It looks like the interface was
never actually exposed on npm so it is safe to rename this one too.
PR Close#41316
Now that other values were removed from `R3ResolvedDependencyType`,
its meaning can now be inferred from the other properties in the
`R3DeclareDependencyMetadata` type. This commit removes this enum
and updates the code to work without it.
PR Close#41231
This instruction was created to work around a problem with injecting a
`ChangeDetectorRef` into a pipe. See #31438. This fix required special
metadata for when the thing being injected was a `ChangeDetectorRef`.
Now this is handled by adding a flag `InjectorFlags.ForPipe` to the
`ɵɵdirectiveInject()` call, which avoids the need to special test_cases
`ChangeDetectorRef` in the generated code.
PR Close#41231
