The downlevel decorator transform (commonly used in the CLI and other
tooling of the ecosystem for enabling JIT ES2015+), is currently
incorrectly dealing with nested classes.
The transform will accidentally visit nested classes (in a constructor)
multiple times and generate duplicated instances of the `ctorParameters`
fields. This does not sound like an issue at first, but the duplicated
`ctorParameters` fields will miss significant type information that has
been elided by the first visit, resulting in generated code like the
following:
```js
let MyClass = /* @__PURE__ */ __name(class MyClass extends UpgradeNg1ComponentAdapter {
constructor(scope, injector3, elementRef) {
}
}, "MyClass");
MyClass.ctorParameters = () => [
{ type: void 0, decorators: [{ type: Inject, args: [$SCOPE] }] },
{ type: Injector },
{ type: ElementRef }
];
MyClass.ctorParameters = () => [
{ type: void 0 }, // <---- NOTE!
{ type: Injector },
{ type: ElementRef }
];
```
PR Close#44281
Fixes an issue where destroy hooks are not set up for `useClass` providers
that rely on `forwardRef` for passing the actual class reference.
Currently the destroy hooks are not captured because forward refs are
not resolved for class providers. In ES2015+ this issue becomes even
more critical if arrow-functions are used for
e.g. `useClass: () => forwardRef(..)`.
This is because arrow functions do not have a prototype, unlike in ES5
where the function assigned to `useClass` would always have a prototype.
In ES2015+ a runtime exception as followed is returned (and doesn't give
any useful indication of the forwardRef issue):
```
TypeError: Cannot read properties of undefined (reading 'ngOnDestroy')
at registerDestroyHooksIfSupported (dist/packages/core/src/render3/di_setup.ts:196:35 <- dist/legacy-test-bundle.spec.js:41508:37)
at resolveProvider (dist/packages/core/src/render3/di_setup.ts:153:9 <- dist/legacy-test-bundle.spec.js:41485:11)
at resolveProvider (dist/packages/core/src/render3/di_setup.ts:70:7 <- dist/legacy-test-bundle.spec.js:41445:9)
at providersResolver (dist/packages/core/src/render3/di_setup.ts:54:5 <- dist/legacy-test-bundle.spec.js:41438:7)
at Object.definition.providersResolver (dist/packages/core/src/render3/features/providers_feature.ts:48:18 <- dist/legacy-test-bundle.spec.js:41600:16)
at resolveDirectives (dist/packages/core/src/render3/instructions/shared.ts:1179:40 <- dist/legacy-test-bundle.spec.js:35611:17)
at elementStartFirstCreatePass (dist/packages/core/src/render3/instructions/element.ts:40:7 <- dist/legacy-test-bundle.spec.js:38432:27)
at ɵɵelementStart (dist/packages/core/src/render3/instructions/element.ts:87:7 <- dist/legacy-test-bundle.spec.js:38453:43)
at ɵɵelement (dist/packages/core/src/render3/instructions/element.ts:180:3 <- dist/legacy-test-bundle.spec.js:38510:5)
at MultipleFormControls_Template (ng:///MultipleFormControls.js:9:9)
```
PR Close#44281
Bundle spec files similar to how it is done within the Angular
Components repo. This should simplify the setup and also speed
up the Saucelab job as only a single spec bundle would need to be
downloaded, compared to having to load hundreds of files through the
Saucelabs tunnel.
Also makes a couple of tests more robust with the emulators/and accounts
for ES2015 test runner changes. The tests should be less reluctant to
such build process changes.
Note for reviewers: Some imports have been simplified here. This work
came from Joey's original WIP for this. It's unclear to me whether this
is still needed, but it sounded like this was necessary for the ESBuild
bundling to work. I have robusted the module resolution plugin though,
so I doubt it's still needed. At the same time though: Not worth
reverting/trying as these changes are nice to have anyway!
Co-Authored-By: Joey Perrott <josephperrott@gmail.com>
Co-Authored-By: Paul Gschwendtner <paulgschwendtner@gmail.com>
PR Close#44281
This is an attempt to increase the stability of the Saucelabs legacy
job by using an emulator recommended by the Saucelabs platform
configurator, explicitly specifying the appium server version etc.
PR Close#44281
When we are going to the definition of an input, we find _both_ the
definition of the input _and_ also look for any directives which have
a selector that matches the input. For example:
```
@Directive({
selector: '[greeting]'
})
export class MyDir {
@Input() greeting!: string;
}
```
With this commit, we now correctly handle the case where inputs and/or
selectors have a dollar sign in them. The dollar sign has special
meaning in CSS, but when we encounter the dollar in a template, we need
to escape it when used as a selector so that it is taken as a dollar
literal rather than a character with special meaning.
Previously, we were not escaping the dollar sign and the CSS parsing
logic would throw an error. The change in this commit prevents that
error from happening, but a `try...catch` is still added in case there
is another unhandled use-case. If this happens, we do not want the
`goToDefinition` operation to completely fail.
Fixes https://github.com/angular/vscode-ng-language-service/issues/1574
PR Close#44268
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
safari handles rem based media queries differently so in order to
provide a similar user-experience to safari users, add a new
safari-only media query for the footer's flex container
resolves#44242
PR Close#44266
This type was exported for the ViewEngine compiler as it needed to
reference the class in its DI codegen. This is no longer a requirement
with Ivy, hence the private export can be removed.
This change prevents an import of `@angular/compiler` to be referenced
in the .d.ts file of `@angular/platform-browser-dynamic`, which is
beneficial for application compilations as that prevents the
`@angular/compiler` .d.ts files from being included in the `ts.Program`
of an application.
Closes#44157.
PR Close#44267
The `.code-anchor` styling was overriding the `.deprecated-api-item` styling.
The `text-decoration` is not needed on `.code-anchor` since it inherits this from the `a` rule in the typography.scss file.
Fixes#44264
PR Close#44275
Cleans up all the tests that had to declare a separate module in order to pass in `entryComponents` when creating components dynamically. This covers almost all of the `entryComponents` usages, except for a few which I've left for now, because they're testing some of the existing leftover `entryComponents` logic in core.
PR Close#44276
This commit removes special functions that were used to run tests in ViewEngine or Ivy only.
Since ViewEngine is deprecated and we no longer run ViewEngine tests on CI, we can cleanup
those special helpers and ViewEngine-only tests.
PR Close#44120
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
Now that the core package has been cleaned up to no longer contain Ivy
switch code, the transform to switch the `PRE_R3` markers to become
`POST_R3` is deleted as well.
PR Close#43891
Add error handling for pipe with component class name in which it has a problem. Add it in ngDevMode, so that it will be a tree-shake away from the production bundle.
PR Close#44081
As node 16 is now active LTS, updating to node 16 is a better choice for our own development. Notably its
support for M1 chips is an important value add for us.
PR Close#44211
In node@16 the URL constructor fails for for a malformed URL such as http://<empty>/. Instead http://_empty_ is
used as this conveys the same information in tests but is correctly formed.
PR Close#44211
Remove incorrect information present in the angular.io animations documentation
stating that animateChild does not work with route transition animations
as that turned out not to be true
This PR effectively reverts the changes make in PR: #44014
For more context see issue #30477
PR Close#44216
currently the aio footer sits outside the mat-sidenav-container, as a
result when the mat-sidenav in over mode appears, the footer is not
placed under the sidenav backdrop, move the footer inside the
mat-sidenav-container so that it does
PR Close#44236
This commit removes most tests that were designated as only covering View
Engine code. It also removes tag filters from CI and local commands to run
tests.
In a few cases (such as with the packages/compiler tests), this tag was
improperly applied, and certain test cases have been added back running in
Ivy mode.
This commit also empties `@angular/compiler/testing` as it is no longer
necessary (this is safe since compiler packages are not public API). It can
be deleted in the future.
PR Close#43884
Currently, when deactivating a route, the detach method of the RouteReuseStrategy is always called
even when we are dealing with a componentless route. If when using a custom strategy we attempt to
detach a componentless route, an exception is thrown causing the navigation to break.
This change prevents this from happening, by not triggering the detach of the route reuse strategy.
Fixes#44239
PR Close#44240
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
In #44214, the `package.json` used to install dependencies for docs
examples was updated, but the corresponding lockfile was not.
Update the lockfile to keep it in sync with `package.json`.
PR Close#44232
Currently the `HttpClient` always wraps errors from XHR requests, but
the underlying errors are always of type `ProgressEvent`, or don't have
a native error if the status code is just indicating failure (e.g. 404).
This behavior does not match in the `TestRequest` class provided by
`@angular/common/http/testing` where errors are considered being
of type `ErrorEvent`. This is incorrect because `ErrorEvent`s provide
information for errors in scripts or files which are evaluated. Since
the `HttpClient` never evaluates scripts/files, and also since XHR requests
clearly are documented to emit `ProgressEvent`'s, we should change the
`TestSupport` to retrieve such `ProgressEvent`'s instead of incompatible
objects of type `ErrorEvent`.
In favor of having a deprecation period, we keep supporting `ErrorEvent`
in the `TestRequest.error` signature. Eventually, we can remove this
signature in the future.
Resources:
* https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/error_event
* https://developer.mozilla.org/en-US/docs/Web/API/ErrorEvent
* https://xhr.spec.whatwg.org/#event-xhr-errpr
Related to: https://github.com/angular/angular/issues/34748.
DEPRECATED: `TestRequest` from `@angular/common/http/testing` no longer
accepts `ErrorEvent` when simulating XHR errors. Instead instances of
`ProgressEvent` should be passed, matching with the native browser behavior.
PR Close#36082
remove the top padding for the homepage article, instead of
having that top padding and moving the element up via a
negative bottom margin in the intro section
note: the result is identical except for when the article's media query
is applied, the difference is barely noticeable anyways
PR Close#44126
Paul Gschwendtner
