Lib's tsconfig is disregarded when lib is built as part of an app

jgbright commented 2 years ago

Current Behavior

If you generate an nx workspace with an app and a lib with different tsconfig options, the lib's ts options will differ when built individually vs when it is built as part of the app. When the lib is built, it uses the tsconfig settings from the lib. When the app is built, the app and the lib are built using the tsconfig settings from the app. This is problematic when the app and lib need different tsconfig options.

I also observe this unexpected behavior when running the web:dev-server executor. That could be due to the same root cause.

Expected Behavior

I expected the lib's tsconfig to be used by the lib both when it is built separately and when it is built as part of the app.

I believe this is either an incorrect assumption on my part or a gap in what the generator produces. I assume that because the generated app and lib each have their own tsconfig files, that they could be configured separately and still work together.

I don't know if this a regression.

Steps to Reproduce

generate an nx workspace using the react preset
generate a react library
use the library's component in the app
configure the lib's code to depend on a tsconfig option that is not compatible with the settings used in the app

See minimal repro repo here: https://github.com/jgbright/nx-multiple-ts-configs

Failure Logs

Transcripts of running various nx commands available here: https://github.com/jgbright/nx-multiple-ts-configs/blob/main/README.md

Environment

➜ nx report

 >  NX   Running global Nx CLI with PNPM may have issues.

   Prefer to use "pnpm" (https://pnpm.io/cli/exec) to execute commands in this workspace.
    TIP  create a shortcut such as: doskey pnx=pnpm nx -- $*

 >  NX   Report complete - copy this into the issue template

   Node : 18.2.0
   OS   : win32 x64
   pnpm : 6.32.17

   nx : 14.1.9
   @nrwl/angular : Not Found
   @nrwl/cypress : 14.1.9
   @nrwl/detox : Not Found
   @nrwl/devkit : Not Found
   @nrwl/eslint-plugin-nx : 14.1.9
   @nrwl/express : Not Found
   @nrwl/jest : 14.1.9
   @nrwl/js : Not Found
   @nrwl/linter : 14.1.9
   @nrwl/nest : Not Found
   @nrwl/next : Not Found
   @nrwl/node : Not Found
   @nrwl/nx-cloud : Not Found
   @nrwl/nx-plugin : Not Found
   @nrwl/react : 14.1.9
   @nrwl/react-native : Not Found
   @nrwl/schematics : Not Found
   @nrwl/storybook : Not Found
   @nrwl/web : 14.1.9
   @nrwl/workspace : 14.1.9
   typescript : 4.6.4
   ---------------------------------------
   Community plugins:

 C:\Repos\nx-multiple-ts-configs :: main ≢  ~1                                                                |  18.2.0 |  100  | 10:31:20  
➜

mratzenb commented 2 years ago

Hi, is there any update on this one, since I am also running into the same problem. The difference in my case is, that I am using an angular application and an angular library. However, the setup is the same as in the provided demo repository. Meaning, that I have different incompatible TypeScript settings between the angular application and the library.

So, is this also a wrong assumption on my side, or is the expected way to refer to the dist folder of the library inside the tsconfig.base.json?

anatter commented 1 year ago

I have the same problem on my side. I want to move an old library which is not in strict mode yet to an app which has strict mode enabled. In the library tsconfig.json I have disabled strict mode, but when building the app the library tsconfig.json settings are ignored.

boompikachu commented 1 year ago

I also have the same problem in nx 15.4.2 with typescript 4.9. Turning on noUncheckedIndexedAccess in app will also apply to lib when building app

admir86 commented 1 year ago

same problem. we can not activate the strict mode for new apps if they have to use the older libraries without enabled strict mode.

zampage commented 1 year ago

I also have this issue when trying to use strict mode for newer apps! 😕

mtrangwx commented 1 year ago

I have similar issue with nx 16.0.1. My shared lib feature generated with @nx/js:lib has strict mode set to true in the tsconfig.json but it is not honoured by the consumer express app generated with @nx/express until I either set the "strictNullChecks": true or the "strict":true in the tsconfig.json for the express app. Does anyone know if there is a document explaining the various tsconfig files used by the apps, libs?

andrey59412678 commented 1 year ago

same problem. would appreciate any possible solutions

peterhodges commented 1 year ago

This has always confused me.

We're not using buildable libs. We have a few apps (each with a tsconfig), and a load of libs (all with their own tsconfig).

When we build an app, it builds everything using the tsconfig from the app (as its the app being built and you can only use one tsconfig!)

We've recently made a few of the libs strict:true so we can improve code over time. Our IDE picks this up during development, but any errors won't fail the build (as the build is running with the application's tsconfig which is strict:false).

It's clear from chatting to the team that this isn't understood well. Many people thought that the library's tsconfig.json would be used during build (although it does make sense that it isn't...)

Further, we recently trialled adding Cypress Component Testing and it seems it's building the lib using the app as a devServerTarget, but with the library's tsconfig (why?). This means that if the lib imports from any other lib with a strict:true config, it'll fail the CCT build, despite the application build still passing.

Not sure how this changes if we make the library buildable...

Why does NX include a separate tsconfig for every library (especially non-buildable ones)?

We could use some better documentation around this stuff I think.

xxgunnery commented 1 year ago

Ran into this problem today, still occurring 10/2023.

Arthur-Fedotiev commented 1 year ago

This has always confused me.

We're not using buildable libs. We have a few apps (each with a tsconfig), and a load of libs (all with their own tsconfig).

When we build an app, it builds everything using the tsconfig from the app (as its the app being built and you can only use one tsconfig!)

We've recently made a few of the libs strict:true so we can improve code over time. Our IDE picks this up during development, but any errors won't fail the build (as the build is running with the application's tsconfig which is strict:false).

It's clear from chatting to the team that this isn't understood well. Many people thought that the library's tsconfig.json would be used during build (although it does make sense that it isn't...)

Further, we recently trialled adding Cypress Component Testing and it seems it's building the lib using the app as a devServerTarget, but with the library's tsconfig (why?). This means that if the lib imports from any other lib with a strict:true config, it'll fail the CCT build, despite the application build still passing.

Not sure how this changes if we make the library buildable...

Why does NX include a separate tsconfig for every library (especially non-buildable ones)?

We could use some better documentation around this stuff I think.

I think we could use ANY documentation around this. This is such a shame this things are found out this way :(

hugo-delatte commented 11 months ago

I also have this problem today... 12/2023

jeenkhoorn commented 9 months ago

I believe there's still no solution or workaround available. 2/2024

e-marfoeldi-carnect commented 5 months ago

I understood here https://nx.dev/recipes/angular/setup-incremental-builds-angular#adjust-the-application-executor, that we need to set options.buildLibsFromSource: false in the app config.

kepelrs commented 3 months ago

I understood here https://nx.dev/recipes/angular/setup-incremental-builds-angular#adjust-the-application-executor, that we need to set options.buildLibsFromSource: false in the app config.

Thanks for sharing. This flag solved it in our project.

nrwl / nx