Angular 13 - ng serve doesn't recompile changes from tsconfig.compilerOptions.paths

[mikerentmeister]

🐞 Bug report

• new
• build
• serve
• test
• e2e
• generate
• add
• update
• lint
• extract-i18n
• run
• config
• help
• version
• doc

Is this a regression?

Just upgraded from Angular 11, so it was a definitely regression for me, but probably mostly due to webpack 5. I'm not sure about Angular 12 since I skipped that one.

Description

When creating an npm library and Angular app in different workspaces, ng serve used to listen for changes to node_modules, and would recompile if any files changed. As we made changes in the library locally, ng serve would pick them up, recompile, and hot reload the changes. It made development of libraries quite easy for local development, because you didn't have to publish to a local npm each time you made changes, install, and recompile. Now, since the introduction of webpack 5, this functionality is broken. Even when using the 2nd option suggested by the team here, ng serve doesn't detect a new change and recompile. (Option 1 isn't an option for me without a major overhaul of all our build pipelines, so I would like to avoid this if possible).

🔬 Minimal Reproduction

1. Clone the following 2 repositories into a directory where they are siblings, and not in the same workspace:
   1a. https://github.com/mikerentmeister/ngx-shared-lib
   1b. https://github.com/mikerentmeister/test-app
   1c.
   
2. Open the ngx-shared-lib project, and run "yarn watch"
3. Open the test-app project and run "yarn start"
4. Make a change to the html, css, or typescript. Notice that the library will recompile, but no changes will be detected in the app using ng serve.

Quick note: generally I wouldn't have the file path in package.json, this was just for demo purposes. Generally the package.json would just have a reference to the @latest for my library, but would expect the tsconfig.compilerOptions.paths to be the source of truth.

🌍 Your Environment

     _                      _                 ____ _     ___ 
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | | 
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | | 
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/
    

Angular CLI: 13.0.1
Node: 16.13.0
Package Manager: yarn 1.22.15
OS: win32 x64

Angular: 13.0.0
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1300.1
@angular-devkit/build-angular   13.0.1
@angular-devkit/core            13.0.1
@angular-devkit/schematics      13.0.1
@angular/cli                    13.0.1
@schematics/angular             13.0.1
ng-packagr                      13.0.3
rxjs                            7.4.0
typescript                      4.4.4

Anything else relevant?
If there is another way of developing a library in a different workspace, and using it locally, I'm all ears. This is a big hit to our Angular development though, because our production library is something that's worked on daily. If we have to stop, recompile, publish npm locally every time we make a change, it will prevent us from upgrading past Angular 11.

[alan-agius4]

Hi @mikerentmeister,

Since you are using the file protocol, it is expected that during watch the changes in the library do not trigger a recompilation of the library. This is because when using the file protocol, yarn will create a copy of the package. In this case the link protocol should be used instead. You can read more about these protocols here.

This however doesn't address the problem as it appears that since Webpack 5.55.0 the version is no longer tracked during watch mode and this results in node_modules being immutable.

I opened an issue with Webpack webpack/webpack#14699

[mikerentmeister]

@alan-agius4 - Thanks for your response. In this scenario, shouldn't the paths in tsconfig.app.dev.json take precedence over whatever is in the package.json, and not require yarn link? Originally I forgot to reference it in the angular.json, but since have updated, and that part still doesn't work.

I did, however, get hot reloading to work using yarn link as you suggested. One thing I noticed though is that incremental builds don't work. When I make a change in my library, all 30 of my modules in my prod app are rebuilt. Anytime I make a change to my library it takes about 1 min for the app to refresh. Any way to improve that performance?

[alan-agius4]

The problem is that the path specified in tsconfig is incorrect, and since the module is present in node_modules, it is fallbacking and using that.

      "@angular/*": ["./node_modules/@angular/*"], // This is needed because of https://github.com/angular/angular/issues/35586
      "ngx-shared-lib": [
-        "../../ngx-shared-lib/dist/common"
+        "../ngx-shared-lib/dist/common"
      ]

This should now work even incrementally and provide you with decent re-build times.

One thing I noticed though is that incremental builds don't work.

Yeah, this is due to this issue I mentioned previously that I open with webpack/webpack#14699, although I must point out that we don't recommand using linking.

[mikerentmeister]

The problem is that the path specified in tsconfig is incorrect, and since the module is present in node_modules, it is fallbacking and using that.

      "@angular/*": ["./node_modules/@angular/*"], // This is needed because of https://github.com/angular/angular/issues/35586
      "ngx-shared-lib": [
-        "../../ngx-shared-lib/dist/common"
+        "../ngx-shared-lib/dist/common"
      ]

After applying this change, removing yarn link, and running ng serve, the hmr took about 30 seconds to rebuild my 30 module project instead of a minute.. I'll take it.

Also a quick note for anyone running into this problem in the future, I also had to list all of my other package dependencies in the paths as well, and ended up looking like this:

{
  "extends": "./tsconfig.app.json",
  "compilerOptions": {
    "paths": {
      "@experlogix/common": [
        "../experlogix-common/dist/common"
      ],
      // These are all needed because of https://github.com/angular/angular/issues/35586
      "@angular/*": ["./node_modules/@angular/*"],
      "rxjs": ["./node_modules/rxjs"],
      "rxjs/*": ["./node_modules/rxjs/*"],
      "devextreme": ["./node_modules/devextreme"],
      "devextreme/*": ["./node_modules/devextreme/*"],
      "devextreme-angular": ["./node_modules/devextreme-angular"],
      "devextreme-angular/*": ["./node_modules/devextreme-angular/*"],
      "@materia-ui/ngx-monaco-editor": ["./node_modules/@materia-ui/ngx-monaco-editor"],
      "@microsoft/*": ["./node_modules/@microsoft/*"],
      "@rxweb/reactive-form-validators": ["./node_modules/@rxweb/reactive-form-validators"],
      "@w11k/ngx-componentdestroyed": ["./node_modules/@w11k/ngx-componentdestroyed"],
      "angular-split": ["./node_modules/angular-split"],
      "d3": ["./node_modules/d3"],
      "monaco-editor": ["./node_modules/monaco-editor"],
      "oidc-client": ["./node_modules/oidc-client"]
    }
  }
}

Thanks @alan-agius4 so much for the help!

[alan-agius4]

I am going to close this issue since the link issue has been confirmed by Webpack that is an issue on their side.

[drewmperkins]

I have been trying for hours to get this to work on Angular 13.1.1. Running an "npm list webpack", I can see the @angular-devkit/build-webpack is using webpack@5.65.0.. which if I followed the commit history on webpack correctly, this bug (of modifying the node_modules directly) was fixed on version v5.64.2.

Somehow, I managed to get @mikerentmeister github projects to work correctly with the linking, but I'm at the point now where I can't get either to work on Angular v13.

Any insight as to if you expect this issue to have already been fixed by webpack, and then propagated to Angular?.?

EDIT: Still trying to get the linking working, looking at the package-lock.json, I have found a clue, the version number is wrong for the linked library, as compared with mike's test-app linked library.

[mikerentmeister]

I ran into problems where sometimes it would work, and others it wouldn't. So what I did instead was use Nrwl Nx and moved all my libraries and apps to a monorepo. It's been great! I highly recommend it!

…

On Sun, Dec 12, 2021, 12:44 PM Drew ***@***.***> wrote: I have been trying for hours to get this to work on Angular 13.1.1. Running an "npm list webpack", I can see the @angular-devkit/build-webpack is using ***@***.*** which if I followed the commit history on webpack correctly, this bug (of modifying the node_modules directly) was fixed on version v5.64.2. Somehow, I managed to get @mikerentmeister <https://github.com/mikerentmeister> github projects to work correctly with the linking, but I'm at the point now where I can't get either to work on Angular v13. Any insight as to if you expect this issue to have already been fixed by webpack, and then propagated to Angular?.? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#22131 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEOXSNAN72OZF7FTNULA4I3UQT3RNANCNFSM5HW5XVYA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[drewmperkins]

@mikerentmeister... Nrwl Nx looks very interesting, I'll probably end up moving my projects as well once this linking stops working considering I've seen it mentioned multiple times not to use linking.

But, I did manage to finally get the linking to work, in case there are others that this affects.

First off, I use npm as my package manager which differs from mikes projects. I kept trying to use the npm link, but I wasn't happy with the naming, so I just ended up using the Windows symbolic linking to name things how I wanted.

mklink /D C:\projectName\node_modules\libraryName C:\libraryName\dist\common

angular.json added the property .. projects.$name.architect.build.options.preserveSymlinks: true

Lastly, as stated previously make sure your library performs a full compilation.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}