-
Notifications
You must be signed in to change notification settings - Fork 25k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Live-Reload UE's when saving changes to HTML or CSS files when using local path library #42810
Comments
I don't recall something having changed in this area since 11.1.1. At least, please check that Could you please share a Github repo with the exact reproduction, so we get the full picture of your setup? Thanks. |
@JoostK No problem! Here it is: https://github.com/longjaso/angular-lib-bug |
Thanks for the repo. It's interesting that it doesn't reproduce for me, but I'm on macOS and used Yarn. Switching to npm now and can try on Windows too... |
AH, it does reproduce when installing with NPM, even on macOS. |
Ok, here's what is going on: NPM installs The initial build succeeds because the compiler resolves the You can workaround this issue by setting |
Thank you @JoostK ! That resolves my issue! |
… imports in .d.ts files The compiler keeps track of how a declaration has been referenced using absolute module imports and from which path the absolute module should be resolved from. There was a bug in how the .d.ts metadata extraction would incorrectly use the .d.ts file itself as resolution context for symbols that had been imported using a relative module specifier. This could result in module resolution failures. For example, when extracting NgModule metadata from `/node_modules/lib/index.d.ts` that looks like ``` import {LibDirective} from './dir'; @NgModule({ declarations: [LibDirective], exports: [LibDirective], }) export class LibModule {} ``` and `/app.module.ts` that contains ``` import {LibModule} from 'lib'; @NgModule({ imports: [LibModule], }) export class AppModule {} ``` then `AppModule` would have recorded a reference to `LibModule` using the `'lib'` module specifier. When extracting the NgModule metadata from the `/node_modules/lib/index.d.ts` file the relative import into `./dir` would create a reference using `'lib'` as absolute module specifier but `/node_modules/lib/index.d.ts` as resolution context path. The latter is incorrect, as `'lib'` needs to be resolved from `/app.module.ts` and not from within the library itself. Fixes angular#42810
… imports in .d.ts files The compiler keeps track of how a declaration has been referenced using absolute module imports and from which path the absolute module should be resolved from. There was a bug in how the .d.ts metadata extraction would incorrectly use the .d.ts file itself as resolution context for symbols that had been imported using a relative module specifier. This could result in module resolution failures. For example, when extracting NgModule metadata from `/node_modules/lib/index.d.ts` that looks like ``` import {LibDirective} from './dir'; @NgModule({ declarations: [LibDirective], exports: [LibDirective], }) export class LibModule {} ``` and `/app.module.ts` that contains ``` import {LibModule} from 'lib'; @NgModule({ imports: [LibModule], }) export class AppModule {} ``` then `AppModule` would have recorded a reference to `LibModule` using the `'lib'` module specifier. When extracting the NgModule metadata from the `/node_modules/lib/index.d.ts` file the relative import into `./dir` would create a reference using `'lib'` as absolute module specifier but `/node_modules/lib/index.d.ts` as resolution context path. The latter is incorrect, as `'lib'` needs to be resolved from `/app.module.ts` and not from within the library itself. Fixes angular#42810
… imports in .d.ts files The compiler keeps track of how a declaration has been referenced using absolute module imports and from which path the absolute module should be resolved from. There was a bug in how the .d.ts metadata extraction would incorrectly use the .d.ts file itself as resolution context for symbols that had been imported using a relative module specifier. This could result in module resolution failures. For example, when extracting NgModule metadata from `/node_modules/lib/index.d.ts` that looks like ``` import {LibDirective} from './dir'; @NgModule({ declarations: [LibDirective], exports: [LibDirective], }) export class LibModule {} ``` and `/app.module.ts` that contains ``` import {LibModule} from 'lib'; @NgModule({ imports: [LibModule], }) export class AppModule {} ``` then `AppModule` would have recorded a reference to `LibModule` using the `'lib'` module specifier. When extracting the NgModule metadata from the `/node_modules/lib/index.d.ts` file the relative import into `./dir` should also be assumed to be importable from `'lib'` (according to APF where symbols need to be exported from a single entry-point) so the reference to `LibDirective` should have `'lib'` as absolute module specifier, but it would incorrectly have `/node_modules/lib/index.d.ts` as resolution context path. The latter is incorrect as `'lib'` needs to be resolved from `/app.module.ts` and not from within the library itself. Fixes angular#42810
… imports in .d.ts files The compiler keeps track of how a declaration has been referenced using absolute module imports and from which path the absolute module should be resolved from. There was a bug in how the .d.ts metadata extraction would incorrectly use the .d.ts file itself as resolution context for symbols that had been imported using a relative module specifier. This could result in module resolution failures. For example, when extracting NgModule metadata from `/node_modules/lib/index.d.ts` that looks like ``` import {LibDirective} from './dir'; @NgModule({ declarations: [LibDirective], exports: [LibDirective], }) export class LibModule {} ``` and `/app.module.ts` that contains ``` import {LibModule} from 'lib'; @NgModule({ imports: [LibModule], }) export class AppModule {} ``` then `AppModule` would have recorded a reference to `LibModule` using the `'lib'` module specifier. When extracting the NgModule metadata from the `/node_modules/lib/index.d.ts` file the relative import into `./dir` should also be assumed to be importable from `'lib'` (according to APF where symbols need to be exported from a single entry-point) so the reference to `LibDirective` should have `'lib'` as absolute module specifier, but it would incorrectly have `/node_modules/lib/index.d.ts` as resolution context path. The latter is incorrect as `'lib'` needs to be resolved from `/app.module.ts` and not from within the library itself. Fixes angular#42810
… imports in .d.ts files (#42879) The compiler keeps track of how a declaration has been referenced using absolute module imports and from which path the absolute module should be resolved from. There was a bug in how the .d.ts metadata extraction would incorrectly use the .d.ts file itself as resolution context for symbols that had been imported using a relative module specifier. This could result in module resolution failures. For example, when extracting NgModule metadata from `/node_modules/lib/index.d.ts` that looks like ``` import {LibDirective} from './dir'; @NgModule({ declarations: [LibDirective], exports: [LibDirective], }) export class LibModule {} ``` and `/app.module.ts` that contains ``` import {LibModule} from 'lib'; @NgModule({ imports: [LibModule], }) export class AppModule {} ``` then `AppModule` would have recorded a reference to `LibModule` using the `'lib'` module specifier. When extracting the NgModule metadata from the `/node_modules/lib/index.d.ts` file the relative import into `./dir` should also be assumed to be importable from `'lib'` (according to APF where symbols need to be exported from a single entry-point) so the reference to `LibDirective` should have `'lib'` as absolute module specifier, but it would incorrectly have `/node_modules/lib/index.d.ts` as resolution context path. The latter is incorrect as `'lib'` needs to be resolved from `/app.module.ts` and not from within the library itself. Fixes #42810 PR Close #42879
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
… imports in .d.ts files (angular#42879) The compiler keeps track of how a declaration has been referenced using absolute module imports and from which path the absolute module should be resolved from. There was a bug in how the .d.ts metadata extraction would incorrectly use the .d.ts file itself as resolution context for symbols that had been imported using a relative module specifier. This could result in module resolution failures. For example, when extracting NgModule metadata from `/node_modules/lib/index.d.ts` that looks like ``` import {LibDirective} from './dir'; @NgModule({ declarations: [LibDirective], exports: [LibDirective], }) export class LibModule {} ``` and `/app.module.ts` that contains ``` import {LibModule} from 'lib'; @NgModule({ imports: [LibModule], }) export class AppModule {} ``` then `AppModule` would have recorded a reference to `LibModule` using the `'lib'` module specifier. When extracting the NgModule metadata from the `/node_modules/lib/index.d.ts` file the relative import into `./dir` should also be assumed to be importable from `'lib'` (according to APF where symbols need to be exported from a single entry-point) so the reference to `LibDirective` should have `'lib'` as absolute module specifier, but it would incorrectly have `/node_modules/lib/index.d.ts` as resolution context path. The latter is incorrect as `'lib'` needs to be resolved from `/app.module.ts` and not from within the library itself. Fixes angular#42810 PR Close angular#42879
Which @angular/* package(s) are the source of the bug?
compiler-cli
Is this a regression?
Yes
Description
Prerequisite: You must have a local-path library in your package.json and be using at least one component from it in your application (whether or not the containing-component is used or not makes no difference). For example:
package.json
"dependencies" : { ... , "my-lib" : "file:..\\my-lib\\dist\\my-lib", ... }
app.component.html
<lib-my-lib></lib-my-lib>
With the setup described above, if you save changes to your application's HTML or CSS files, the server crashes throwing the error below - causing you to have to restart your server every time you make an HTML/CSS change. If you remove all component references that originate from the locally-pathed library then you no longer have this problem.
Please provide a link to a minimal reproduction of the bug
No response
Please provide the exception or error you saw
Please provide the environment you discovered this bug in
Anything else?
This was working in 11.1.1 and I updated to 11.2.14. This is when it broke. I tried updating to 12.1.1 to see if there was a patch for it but this didn't work.
The text was updated successfully, but these errors were encountered: