feature: acknowledge tsconfig paths

What I would like to do is have multiple packages in the same repo. So far everything works well EXCEPT, I have one package that depends on another I have the paths defined in the tsconfig so that I can use the correct module name during development and testing.

{
   ...
   "baseUrl": "./",
    "paths": {
      "@livesafe/common": [
        "./src/app/common/public_api.ts"
      ],
      "@livesafe/dialog": [
        "./src/app/dialog/public_api.ts"
      ]
    }
}

Everything works great for dev but falls over when trying to generate the bundle for @livesafe/dialog I get the following error.

Looking through the code I couldn’t find a way to configure paths for the ngc step of the build.

[deanpeterson]

I have a similar problem. Following a suggestion for making environment variables reusable, I added the following to the tsconfig: "compilerOptions": { . . . "paths": { "@env/*": ["environments/*"] } },

That is so I can use something like: import { environment } from "@env/environment"; Rather than a relative path to the evironment.ts file that exists outside the modules base folder I will be packaging up. Of course when I go to run npm run build:lib to execute ng-packagr I get the error that @env module does not exist. I am having a little trouble deciphering some of the suggestions above. Is there an approach that will work to fix this problem? I would like to use environment variables in place of hard coding values that will change based on the application my npm package is running in. I thought I had a solution with @env/environment but ng-packagr will not allow it.

[dherges]

No, not yet. There’s two sides of it:

1. improving the programmatic API for better tsconfig customization (it’s a mess, there’s a default tsconfig, an entry point tsconfig, and a build-time tsconfig). What users want is to configre the entry point tsconfig. Right you, the API only allows to configure the default.
2. multi-package builds: something like dependsOn: [ "path/to/other/package.json" ] that will build the dependee package first and then build the dependent.