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

🐞 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.

[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]

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.