-
Notifications
You must be signed in to change notification settings - Fork 12k
tsconfig paths not respected #8117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Dupe of #8036 |
Thanks @clydin. If this is by design and the pre-1.2.6 behavior should be considered a bug rather than a feature (as per the other thread), then is or will there be a recommended way to configure module aliases without ejecting? CC @filipesilva and @hansl Edit: Contrary to the other issue description, this is only reproducible for me starting with 1.3.2. Looks like 7d7799b is the root cause. Edit 2: @clydin, my report here must not have been clear enough if it sounded like a dupe of #8036. I ran into #8036 separately just now, and that isn't what I'm reporting here. The problem here isn't that there's a build failure or any kind of error, but rather than the aliasing simply isn't happening. In the example demo I provided, the actual |
It's the same underlying cause. In the other issue's case, there was no original module so without aliasing there's going to be a build error due to the missing module. |
@hansl can you clarify what the intended behaviour is in this case? |
this bug is also breaking npm link -ed packages with an @angular/core dependencies |
Thanks @slartibardfast for referring my comment, I think also have a more descriptive error could help in this case |
I would love to see an statement from the developers about this issue. |
@domdeger The issue here is that tsconfig's path mapping options only apply to TypeScript files. This was fixed in 1.3.2/1.4.0. As a result there is currently no method (outside of eject) to provide javascript module resolution aliases. For linked library use in general, please refer to the wiki story found here. Note however that without javascript module aliasing, the TS path mapping settings are only partially effective. The build/serve command option |
@clydin Thank you very much for your fast answer. I have read the wiki story really carefully. But the problem still persists for me. As I have mentioned, i have already invested two or three days just fixing this problem with the only workaround deleting the node_modules from my linked libs. You said, that this concerns typescript compilation which is interesting because my setup was about ts. I have following setup: So Lib1, Lib2 contains plain ts because it has no special build logic. I created those projects to outsource common functionality i use for multiple projects. I would like to leave compilation up to the project which references them. So this issue also persists if I setup aot compilation for my libs and reference the compiled js, which also results in sub node_modules getting compiled. I do not understand how --preserve-symlinks could help me in this regard. I am sorry if this topic is not related to the initial issue of this thread. If so could you maybe tell me where i can get help? Normally i don't spam on github threads to get help, but i have worked on this issue for 3 working days and couldn't find an effective solution. Thank you :) |
@filipesilva here is my repro: Versions.
Repro steps.
The log given by the failure.
|
Are there any plans to add a different method of module aliasing? Pinning the CLI to 1.2.6 works for now, but I don't want to get left behind as new features are introduced or risk compatibility issues with Angular 5 and beyond. |
Update here for Angular5. Problems seem to persist.
I migrated my project and libs to angular5 but there seems to be something odd again with the module resolution as it is giving:
Which is related to module resolution because the error fades away when i delete the angular folder in node_modules the linked libraries. But then i have another problem with rxjs because Observables from angular/http do not have the imported operators anymore. I am pretty concerned about this. I would really appreciate if the angular team could explain how we can use npm linked libraries for development? I guess this is not a rare use-case that one wants to share components over multiple projects. |
FYI, for anyone else needing the pre-1.2.6 behavior, the solution I landed on is using the latest Angular/CLI/etc. and just overwriting @domdeger, is that tsconfig from a CLI project or an ejected one? You shouldn't need to list every package you're using in the tsconfig like that, unless I'm missing part of what you're trying to do. |
@buu700 This is the tsconfig from a CLI project. So this is consuming some npm linked libs. If i use @NgModule in a linked lib and have installed the @angular/core because i want autocompletion while developing angular-cli now compiles the package @angular/core twice resulting in duplicate/incompatible types. |
Ah, okay. Haven't run into that before so don't have any ideas, but maybe the paths plugin thing from my last comment could also be a quick fix for that. |
The @buu700 method works!!! |
What is strange for me is that this only occurs when I am building in travis. |
Any news guys? waiting forward bugfix( |
Migrating a huge application to angular 5 and angular-cli 1.6, This is so far the most blocker i have encounter. Should we avoid path alias as a practice? |
@hansl Сould you please tell us, when does this fix is going to be performed? |
@buu700 @domdeger this fix can be used with https://www.npmjs.com/package/patch-package |
Interesting, thanks for the tip! That looks like a really neat solution for this type of thing; I'll definitely use it in the future. |
FYI: Path package works great for me, with @buu700 patch |
Previously we filtered our path mapping resolver to only be used on typescript. The correct behaviour is unclear; tsc does not resolve JS files, only TS. But there is a lot of value to use path mapping to resolve JavaScript files, and it replaces the webpack alias configuration option. Because of that value it was decided to fix this. Fixes angular#8117.
Previously we filtered our path mapping resolver to only be used on typescript. The correct behaviour is unclear; tsc does not resolve JS files, only TS. But there is a lot of value to use path mapping to resolve JavaScript files, and it replaces the webpack alias configuration option. Because of that value it was decided to fix this. Fixes #8117.
Previously we filtered our path mapping resolver to only be used on typescript. The correct behaviour is unclear; tsc does not resolve JS files, only TS. But there is a lot of value to use path mapping to resolve JavaScript files, and it replaces the webpack alias configuration option. Because of that value it was decided to fix this. Fixes #8117.
Oh, thank you, guys)
|
This dosen't appear to have solved it for this case. |
Nevermind, I had it misconfigured.
credit to @clydin for pointing that out |
I have the same mistake as @domdeger, only that it happens to me when I run "npm run test" with karma help please. Error: NullInjectorError: No provider for IterableDiffers! |
@johnking |
@domdeger, |
I have the same issue with a linked in library and @buu700 patch works for me as well! |
@domdeger it works pretty well, and it is well documented. |
Hi, I have recently updated to v1.7.0 of the CLI and I am now facing this issue, which is causing multiple angular packages to bundled. My error in particular is:
I am experiencing the classic symptoms such deleting @angular from the linked library cause the errors to disappear despite having already configured the paths in the tsconfig.app.json and used preserveSymlinks. Is it possible that there has been some regression? From looking at the source of Although @buu700's patch worked for me in previous version; It is now too far diverged from the latest code to use. Version info:
Any help would be greatly appreciated. |
Yeah, this is also plaguing me as well. The most I can do is make it compile before running into module resolution run-time errors complaining about duplicate modules and Angular not knowing which one to choose. Anyone who is writing anything modular that wants to break up their application into more manageable libraries will need to "npm link" locally at some point in time. Making one small change then "npm publish" and "npm install" on all other consuming apps can't be the way forward. Doing complicated "npm link" with dist folders outside the structure can't be the way forward. Everything else is just a huge workaround. Yes, I know that at some point TS made the packaging more strict as to not allow shipping of ".ts" files. But this is seriously impeding a very common development workflow. The worst part is that no one wants to take full responsibility for the issue. Is it an issue with Webpack, is it an issue with TS or Angular? All of the respective forums have their own variant/version of this issue. This is the sort of thing that keeps holding me back in terms of adopting the latest and greatest Angular CLI version. I have to either do an "ng eject" or manually patch. There have been massive enhancements over the past couple of versions and I really appreciate that because I really see the work that's been going on into the framework. I guess any guidance here would be very much appreciated. |
@davidcblaney i am facing the same issue. is it resolved for you? any help will be much appreciated. |
For guys using webpack. You can resolve the dependencies by specifying absolute path to to your current project's node_modules. |
Previously we filtered our path mapping resolver to only be used on typescript. The correct behaviour is unclear; tsc does not resolve JS files, only TS. But there is a lot of value to use path mapping to resolve JavaScript files, and it replaces the webpack alias configuration option. Because of that value it was decided to fix this. Fixes angular#8117.
I found myself struggling with something that appeared to very strongly correlate with this issue, resulting in getting StaticInjectorError for my dependencies. I had a module that I was importing into the TestBed configuration in the spec file, which defined some providers for some services. The module was using the aliased imports from the dist directory, as is correct. The spec file however was using a relative import for the service. I solved this by using aliased paths everywhere. My case resulted, I think, from a structural decision we have made. We have an interface library, and a corresponding implementation library that satisfies all the interfaces in the first. We then use providers with useClass to allow the application code (and tests) to be built directly against the interface, so that the implementations can be swapped out at will. All of the code (spec and library) in the implementation library was using the correct aliased paths for dist, whilst all the spec code in the interface library was using relative paths. In conclusion: anybody still finding themselves coming to this thread, make sure you are using your aliased paths in all cases |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Bug Report or Feature Request (mark with an
x
)Versions.
Repro steps.
ng serve
https://github.com/buu700/ngcli-pathsEither "success" or "failure" will be displayed.
Desired functionality.
tsconfig paths should be treated as equivalent to
resolve.alias
values, as far as I understand. However, it seems that they're only applying to imports from within the Angular project itself, not third-party modules. (I'd thought that this worked in the past, so it may be a recent regression.)In this example, we're importing a node module
test63987
that imports and re-exports an arbitrary second module (libsodium-wrappers-sumo
). Setting"libsodium-wrappers-sumo": ["libsodium-replacement"]
in tsconfig does not have the desired effect. However, ejecting and adding the equivalentalias
to webpack.config.js does work as expected.Mention any other details that might be useful.
Project this affects is https://github.com/cyph/cyph.
Edit: Workaround: Install the latest Angular/CLI/etc. and replace
node_modules/@ngtools/webpack/src/paths-plugin.js
with https://github.com/buu700/ngtools-webpack-tmp/blob/master/src/paths-plugin.js.The text was updated successfully, but these errors were encountered: