Angular-cli: xi18n extraction should be based on code referenced/entrypoints

[intellix]

Bug Report or Feature Request (mark with an x)

- [x] bug report -> please search issues before submitting
- [ ] feature request

Versions.

Angular CLI: 1.5.0
Node: 8.7.0
OS: darwin x64
Angular: 5.0.0
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

@angular/cli: 1.5.0
@angular-devkit/build-optimizer: 0.0.32
@angular-devkit/core: 0.0.20
@angular-devkit/schematics: 0.0.35
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.8.0
@schematics/angular: 0.1.1
typescript: 2.4.2
webpack: 3.8.1

Repro steps.

Use monorepos pattern for having multiple apps and libs and then extract strings for each app. They all contain references to all strings whether used or not.

Command:
https://github.com/intellix/nx-cli/blob/master/package.json#L13

References to strings in other apps:
https://github.com/intellix/nx-cli/blob/master/apps/red/src/locale/messages.xlf#L26

References to lazy module that's not used/referenced by that app:
https://github.com/intellix/nx-cli/blob/master/apps/red/src/locale/messages.xlf#L77

Desired functionality.

I'd like extraction (and pretty much everything through ngc) to only be based on context of the app and it's entrypoints (static or lazy).
In the example repository, the Red app doesn't reference or have a loadChildren reference to LazierModule but still gets strings extracted for it and all the other apps.

We've got feature modules defined as libs and a couple of apps that include some of them. The product owners of apps are confused why they're translating strings for features they don't have and for other apps

Mention any other details that might be useful.

Schematics: https://nrwl.io/nx/
Repository: https://github.com/intellix/nx-cli

[ocombe]

Ok I can confirm the problem but it's a bit complex: when we create the typescript program, we add all of the files from the workspace folders ("src" for a normal cli app, or "apps" & "libs" for nx projects) regardless of wether they are actually used by your app, the reason is that we need to list all of those files in case they are lazy loaded (which means that they are not linked by the imports of your main.ts).
The extraction tool from the compiler-cli will extract i18n from all of the files that are defined in the ts program because it uses typescript transformers now, which means that instead of compiling the whole app, each file is treated separately and it doesn't know the structure of your app when it extracts.
This leads to the problem that you get i18n from other apps as well.

An easy workaround is to create a tsconfig file for each app (currently in your project they all use the same "tsconfig.app.json". Once you have a tsconfig file for each app, update the "exclude" option to exclude the other apps. For example this would be the tsconfig file for the "red" app:

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "outDir": "./out-tsc/app",
    "module": "es2015",
    "baseUrl": ".",
    "paths": {
      "@nx-cli/*": [
        "libs/*"
      ]
    }
  },
  "exclude": [
    "**/*.spec.ts",
    "**/*.e2e-spec.ts",
    "node_modules",
    "tmp",
    "apps/blue/**/*",
    "apps/green/**/*"
  ]
}

This should probably be done by nx for questions of performance since nx assumes that each apps are independent except for what's in the "libs" folder. The cli shouldn't know about the other apps when it's building a specific app (ping @vsavkin), excluding those other apps will probably improve performance a lot (no more transformers running for all those apps, no more watchers, ...).
I'm not sure if this is something that could be fixed in the cli as well (ping @filipesilva).

[filipesilva]

Going through @ocombe's findings, I think the individual tsconfig approach is the right one. The tsconfig file is where one defines which TS files are part of a compilation, so if you using a tsconfig that includes all TS files then they will all be included.

Maybe we could 'force' include only the app entry point. We actually do that for polyfills in tsconfig.spec.json, but we do it for historical reasons... it's not really correct, but not a big problem due to how that file includes things.

But overall fiddling with user tsconfig files is likely to lead to problems. For instance, if we added "files": ["main.ts"] to src/tsconfig.app.json, your lazy routes would not be included. And we'd have to provide some kind of API for that overriding, and that quickly gets out of hand.

[intellix]

As a workaround I've created separate tsconfigs and I guess it'll work for our case use :) https://github.com/intellix/nx-cli/commit/3b6d2cddc1c63a14e6192cb902be3f7b25c3d351

I think it's important enough a reason for NX to generate those tsconfigs when you generate apps there

[ocombe]

Nice, fyi you can extend another tsconfig file instead of copy pasting everything in each file. If you only need to change the exclude, it's easier to have a generic app config file, extend it and just change that

[filipesilva]

I think this is a non-issue now that CLI uses a workspace file and can have several distinct applications, each of them with its own tsconfig files. Let me know if that's not the case.

[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._}