Nx: Cannot serve @nrwl/node project referencing a buildable library

[JakeGinnivan]

Current Behavior

Similar to https://github.com/nrwl/nx/issues/3131, if you try to reference a library with a build target then it cannot be resolved by webpack.

Expected Behavior

It shouldn't matter if a library is buildable/publishable or neither, it should be able to be referenced by applications.

Steps to Reproduce

Create a new workspace, then

yarn add @nrwl/node
nx generate @nrwl/node:application --name=test-app
nx generate @nrwl/node:library --name=test-lib --buildable --importPath=@test-org/test-lib

Then update apps/test-app/main.ts

import { testLib } from "@test-org/test-lib";

console.log('Hello World!');
console.log(someBuildableLib())

Failure Logs

yarn nx serve test-app

Results in error:
Module not found: Error: Can't resolve '@test-org/test-lib'

If you remove test-lib.architect.build from workspace.json the problem goes away.

Environment

  nx : Not Found
  @nrwl/angular : Not Found
  @nrwl/cli : 10.3.1
  @nrwl/cypress : Not Found
  @nrwl/eslint-plugin-nx : 10.3.1
  @nrwl/express : Not Found
  @nrwl/jest : 10.3.1
  @nrwl/linter : 10.3.1
  @nrwl/nest : Not Found
  @nrwl/next : Not Found
  @nrwl/node : 10.3.1
  @nrwl/react : Not Found
  @nrwl/schematics : Not Found
  @nrwl/tao : 10.3.1
  @nrwl/web : Not Found
  @nrwl/workspace : 10.3.1
  typescript : 4.0.3

[pf1gura]

I encountered the same issue when refactoring one of my repo a while ago and today I had time to look into it more. I have Nest.js application with both node and Nest.js libraries. But since Nest.js and node use same builder under the hood I am not sure if that should really matter.

I don't have solution to that yet, but I discovered two things:

1. Application will be served successfully if you build the library first, and start development server later. But that is not a real solution, at least for me, during development. I don't want to rebuild libraries manually every time I change them.
2. Application will be served successfully if your typescript alias and library package name (in libs/lib-name/package.json) are different

I am not sure yet what is the connection between all of this, but as a quick workaround I changed all package names. This is not viable solution since many projects might want to use same names inside monorepo and when using the package downloaded from npm.

Also, everything works well with same setup, but when serving Angular application. Libraries can be buildable/publishable, and none of the stuff from above has to be done. Everything works as expected out of the box.

[pf1gura]

Solution

I managed to fix the issue by adding "buildLibsFromSource": true to the build target of the application.

This will basically cause the libraries to behave as they weren't buildable/publishable in the context of that application. They will be bundled in the main.js file of generated application. And original libraries still have their own build target that can be used to build and publish the library if that is something we want.

Explanation

That is what I found about this flow. When this option is disabled, nx generates temporary tsconfig with path mappings in tmp/apps/app-name folder that expects libraries to be built into their destination location (dist/lib/lib-name by default). This tsconfig is then used by the application to locate the dependencies.

• tsconfig is generated here: https://github.com/nrwl/nx/blob/2824794a92913624e59d00201ef5dfa936f842fe/packages/workspace/src/utils/buildable-libs-utils.ts#L133
• buildLibsFromSource option is handled here: https://github.com/nrwl/nx/blob/2824794a92/packages/node/src/builders/build/build.impl.ts#L40

[treveshan]

Solution

I managed to fix the issue by adding "buildLibsFromSource": true to the build target of the application.

This will basically cause the libraries to behave as they weren't buildable/publishable in the context of that application. They will be bundled in the main.js file of generated application. And original libraries still have their own build target that can be used to build and publish the library if that is something we want.

Explanation

That is what I found about this flow. When this option is disabled, nx generates temporary tsconfig with path mappings in tmp/apps/app-name folder that expects libraries to be built into their destination location (dist/lib/lib-name by default). This tsconfig is then used by the application to locate the dependencies.

• tsconfig is generated here: https://github.com/nrwl/nx/blob/2824794a92913624e59d00201ef5dfa936f842fe/packages/workspace/src/utils/buildable-libs-utils.ts#L133
• buildLibsFromSource option is handled here: https://github.com/nrwl/nx/blob/2824794a92/packages/node/src/builders/build/build.impl.ts#L40

Hi could you please provide a sample of how you solved this. I'm currently having an issue like this on my angular prod build only

[pf1gura]

@treveshan what is the issue, exactly? Do you have an error message or something else? For me, Angular builds work normally.

[treveshan]

@treveshan what is the issue, exactly? Do you have an error message or something else? For me, Angular builds work normally.

https://github.com/nrwl/nx/issues/4211#issue-757667269