- [x ] bug report -> please search issues before submitting
- [x ] feature request
angular 5.0.0
ngtools/webpack 1.8.0
we have application that uses umd angular libraries which reference current application modules. with new compiler-cli this is not supported as it does a check if module resides within node_modules folder. with old cli we were able to use webpacl alias's to resolve this. but seems like with new version we are not able to complete this change.
Gives below error:
Error: Trying to import a source file from a node_modules package: import /Users/123/stash/features/xyz-ui/app/xyz/core/coreModule.ts from /Users/123/stash/features/xyz-ui/node_modules/@ xyz/ux/ux.ngfactory.ts
Ex:
our application has core module under app/core/coreModule.ts and also contains app/core/public_api.ts (which exports coreModule.ts)
application also uses umd bundled library from node_modules/@xyz/ux folder using @xyz/ux import. and this folder reference app/core/coreModule through @xyz/core import.
our build tscofnig contains paths to point @xyz/core to app/core/public_api.ts.
with new compiler and ngtool/webpack builder we are not able to build the app as compiler_host.ts throws error from below line.
Appreciate if this can be resolved with next minor version.
Same as @mlakmal, but only in AOT not with ng serve.
It's seems to be clearly impossible to build an app in AOT mode with a node_module importing environments/* or any others paths relative to the current project
Somebody knows a quick fix to bypass this ?
Previous CLI's version could be compatible with angular 5.x ?
Thx a lot.
Our quick workaround was just to comment out the line in node_modules\@angular\compiler-cli\src\transformers\compiler_host.js that's throwing the exception (line 181). Everything compiles fine after that, so it's definitely not a hard stop rule.
For production, with continious delivery, devops or similar, it could be a real hard stop ^^.
Anyway, your reply is welcome and really usefull.
Thank you @djimoh5 .
An other quickfix/fallback: compile without AOT and waiting for new release/fix, not perfect but it works.
Any update on this?
Not really convenient to override compiler-cli to share env file between external modules and an app.
We use this webpack plugin as a workaround:
https://pastebin.com/30qJPrNt
Basically it's just a copy-paste of internal webpack AngularCompilerPlugin code.
Hey @Paulskit, what exactly have you done? I cannot open the repo :|
@drakenfly Here is another link: https://pastebin.com/30qJPrNt
Workaround is to try regular resolving (the same as AngularCompilerPlugin already does) for modules that doesn't match (in ACP opinion).
Works great so far.
Sorry if I bother you with this, but how have you managed to integrate this in a CI environment with angular cli? As far as I know, you cannot modify webpack without detaching the app?
I use webpack directly with @ngtools/webpack. Angular CLI unfortunately doesn't offer enough flexibility for our needs.
Ok. For several reasons, I cannot eject the app here in our setup :(
Are there any plans to fix this in future CLI releases?
Unfortunately for now, we went with something like this for our build process:
compiler_host="node_modules/@angular/compiler-cli/src/transformers/compiler_host.js"
patched="$compiler_host"".bak"
if [ ! -f "$patched" ]; then
sed -i\'.bak\' \'186,188d\' "$compiler_host" && touch "$patched";
fi
I also hit the same issue. We have a shared module with typescript files and those modules are consumed by our main app.
update: --aot false fixes the issue but we'd like to use aot if possible
Still happening with v6
Still happening with v6.9 --> NPM Version, my bad
Edit:
Still happening with Angular v8.0.2 - CLI v8.0.4
This has gotten a bit stale. Can anyone reproduce this with 8.1.0?
@Splaktar
I just updated my answered, mixed up my npm version with angular and cli
Can someone provide a reproduction repository that we can clone and see this error please?
Can someone provide a reproduction repository that we can clone and see this error please?
It's not as simple as a single repo, one needs two repos and at least one of them published to npmjs or other NPM repo.
I'll try to do it but I don't know if I have time.
But sure this is problematic in complex enterprise architectures, and if there is no explicit need for this check, it should be removed.
Unfortunately this is the situation for us too.
While we are slowly migraing to monorepo we still have some (internally) published libraris, and if those depend on the libraries already in the monorepo we get this error. For now, we patch angular's compiler host, the current position of the error is on line
235 we nuke the whole else block with this: (angular 8.2.14)
sed -i.bak '234,236d' "$compiler_host" && touch "$patched";
and everything works fine
thanks @jensbodal for the solution script
It looks like this solution does not work in production mode. I get errors saying my service (which comes from the internal library) does not exists. And when I look at the output main.js there is indeed no reference to the service but the one place it is injected.
It is a component with 7 injected services and it's definition looks like this : [FeaturesServiceRestPublic,ApplicationServiceRestSecured,Sc,bl,J,xc,_c]
The first two where not imported not minified.
I endded up removing the "paths" config and putting a symbolic link directly into "node_modules" folder using a "postinstall" script
"postinstall": "ln -sfn ../library/dist node_modules/@company/library"
This requires the "preserveSymlinks" set to true inside angular.json build options
Closing as this has been open for a couple of years and so far we didn鈥檛 receive a reproduction that we can look at.
Kindly update to the latest version of Angular and it the problem persists please open a new issue with a minimal reproduction.
Thanks
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._
Most helpful comment
@drakenfly Here is another link: https://pastebin.com/30qJPrNt
Workaround is to try regular resolving (the same as AngularCompilerPlugin already does) for modules that doesn't match (in ACP opinion).
Works great so far.