Fantastic work on this. I'm looking at it as a way to deal with the problem with tsconfig path aliases not being recognized during ng-packagr bundling.
This is a widely reported issue with ng-packagr. But it is actually an issue with TypeScript itself: Namely that path aliases are not translated into relative paths during compilation. There are a multitude of TS issues with hundreds of comments and pleas (just one example), but few viable solutions.
The end result is that anything using a tsconfig path alias will fail to be located during bundle creation. You end up with warnings saying "No name was provided for external module '@company/myapp/products.component' in output.globals – guessing 'products_component'", and you end up with an invalid UMD bundle.
Unfortunately, I'm converting parts of an existing app to a shared library, and I really don't want to have to go through and replace the imports across 1000+ files. Not to mention how horribly ugly the relative imports are just to look at.
Do you have any advice on a solution that would allow some logic to run before/after the compileNgc step, or possibly before the writeBundles step, that could adjust things so the paths can be resolved for the bundler? It looks like the CLI builds the compilation results in memory, so I'm not sure there's much that can be done, but I figured I'd ask. I know there are a lot of people who'd be interested in a solution to this.
Fantastic work on this. I'm looking at it as a way to deal with the problem with tsconfig path aliases not being recognized during ng-packagr bundling.
This is a widely reported issue with ng-packagr. But it is actually an issue with TypeScript itself: Namely that path aliases are not translated into relative paths during compilation. There are a multitude of TS issues with hundreds of comments and pleas (just one example), but few viable solutions.
The end result is that anything using a tsconfig path alias will fail to be located during bundle creation. You end up with warnings saying "No name was provided for external module '@company/myapp/products.component' in output.globals – guessing 'products_component'", and you end up with an invalid UMD bundle.
Unfortunately, I'm converting parts of an existing app to a shared library, and I really don't want to have to go through and replace the imports across 1000+ files. Not to mention how horribly ugly the relative imports are just to look at.
Do you have any advice on a solution that would allow some logic to run before/after the compileNgc step, or possibly before the writeBundles step, that could adjust things so the paths can be resolved for the bundler? It looks like the CLI builds the compilation results in memory, so I'm not sure there's much that can be done, but I figured I'd ask. I know there are a lot of people who'd be interested in a solution to this.