Build of application triggers also build of library

🐞 Bug report

Command

• new
• build
• serve
• test
• e2e
• generate
• add
• update
• lint
• xi18n
• run
• config
• help
• version
• doc

Is this a regression?

No

Description

Building the application in multiproject workspace has an unexpected side effect of rebuilding also a library whose module is imported in the application.

🔬 Minimal Reproduction

1. Create a fresh multiproject workspace containing a library and an application:

ng new my-workspace --create-application=false
cd my-workspace
ng generate library my-lib
ng generate application my-app

1. Build a library using ng build my-lib --prod
2. Note the content and timestamp of built package.json in dist/my-lib
3. Import library’s module into application’s AppModule:

// my-app's app.module.ts
import { MyLibModule } from 'my-lib'; // add this

1. Build an application using ng build my-app --prod
2. Note that content and timestamp of package.json in dist/my-lib has changed. Most interestingly it is no longer a production build of a library as a package.json now contains

"scripts": {
    "prepublishOnly": "node --eval \"console.error('ERROR: Trying to publish a package that has been compiled by NGCC. This is not allowed.\\nPlease delete and rebuild the package, without compiling with NGCC, before attempting to publish.\\nNote that NGCC may have been run by importing this package into another project that is being built with Ivy enabled.\\n')\" && exit 1"
  }

which prevents it from being published.

✔️ Expected result

Building an application should not have a side-effect of rebuilding also imported library. What’s worse is that application build ignores the fact that -prodwas used and when building the library it produces non-prod build.

This unexpected behavior gets especially nasty when running CI where you build a prod build of your library (ready to publish), then build an application on which you run some tests to see if your lib behaves correctly and if so you want to publish the library - well you can not as it has been rebuilt non-prod 😞

Also in the docs at https://angular.io/guide/creating-libraries#building-and-rebuilding-your-library it is stated that you need to build you library when you make changes to it so they are reflected in your app, but it seem that due to this issue it is build for you…

🌍 Your Environment

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

Angular CLI: 10.1.1
Node: 14.10.1
OS: linux x64

Angular: 10.1.1
... animations, cli, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router
Ivy Workspace: Yes

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.1001.1
@angular-devkit/build-angular     0.1001.1
@angular-devkit/build-optimizer   0.1001.1
@angular-devkit/build-webpack     0.1001.1
@angular-devkit/core              10.1.1
@angular-devkit/schematics        10.1.1
@ngtools/webpack                  10.1.1
@schematics/angular               10.1.1
@schematics/update                0.1001.1
ng-packagr                        10.1.0
rxjs                              6.6.3
typescript                        4.0.2
webpack                           4.44.1

[petebacondarwin]

@alan-agius4 has explained it correctly here. You should publish your libraries in ViewEngine format. They will be consumed as-is by ViewEngine applications or be compiled by ngcc after installation for Ivy applications.

When you are testing your library, you may choose to test both the ViewEngine and Ivy versions. There are actually three formats since you could build the library directly with Ivy or build it with ViewEngine and then compile that to Ivy using ngcc.

For most local testing it is OK to just build the library directly with Ivy and then consume that directly in your test app. This is the fastest and simplest approach. You can do this by not using the --prod flag on the library build.

But in order to distribute it, you must build it with ViewEngine, this is done via the --prod flag on the library build. If you consume the output of this build in an Ivy test project, then ngcc will update it to Ivy. You should not publish this updated code. So @alan-agius4’s suggestion is to pack the output of the --prod build into a .tgz file before testing it with the Ivy app, and then you can publish that file safely to npm if you wish.

Finally if you want to test the ViewEngine version locally, then you need to build your test app in ViewEngine mode, which you can do by providing a new tsconfig file and setting up a new CLI build target.

[angular-automatic-lock-bot[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.}