Repository navigation
Webpack config not finding nested node_modules #6248
Description
Bug Report or Feature Request (mark with an x)
- [x] bug report -> please search issues before submitting
- [ ] feature request
Versions.
@angular/cli: 1.0.2
node: 6.10.1
os: darwin x64
@angular/common: 4.1.1
@angular/compiler: 4.1.1
@angular/core: 4.1.1
@angular/forms: 4.1.1
@angular/http: 4.1.1
@angular/platform-browser: 4.1.1
@angular/platform-browser-dynamic: 4.1.1
@angular/router: 4.1.1
@angular/cli: 1.0.2
@angular/compiler-cli: 4.1.1
Repro steps.
- Clone the repo: https://github.com/jshcrowthe/ng-cli-nested-node-modules.git
- Enter the repo dir
- Run
npm install - Run
ng serve - Observe error from
ng servecommand
The log given by the failure.
ERROR in ./~/firebase/app/shared_promise.js
Module not found: Error: Can't resolve 'promise-polyfill' in '$PATH_TO_REPO/nested-node-module/node_modules/firebase/app'
@ ./~/firebase/app/shared_promise.js 22:35-62
@ ./~/firebase/app/firebase_app.js
@ ./~/firebase/app.js
@ ./src/app/app.component.ts
@ ./src/app/app.module.ts
@ ./src/main.ts
@ multi webpack-dev-server/client?http://localhost:4200 ./src/main.ts
Desired functionality.
Webpack should compile this module and it's nested children correctly
Mention any other details that might be useful.
n/a
Activity
clydin commentedon May 9, 2017
Unfortunately, yes, it currently doesn't work but a solution is in progress.
Note that everything works with
yarnas it will hoist the dependencies to the top level.Also, I would highly suggest using https://github.com/angular/angularfire2 which makes integrating firebase into an Angular app quite quick and painless.
filipesilva commentedon May 10, 2017
@hansl this is the problem we talked about yesterday with Firebase.
clydin commentedon May 11, 2017
Enabling the use of the Node.js module resolution algorithm (a minor code change) will ensure the correct and proper module is used within an app. As witnessed in this issue as well as #3023, this is a real and repeatable concern.
The change will cause issues in two main situations:
The first is essentially a non-issue as the libraries are improperly packaged.
The second is a concern and will cause trouble to those wishing to use linked Angular library packages in development scenarios. However, ensuring an application can resolve and use the proper module (and allow the application to properly function) would generally outweigh the added developer inconvenience for a use case that while not uncommon is not extremely common either. This point, however, is definitely one for discussion.
filipesilva commentedon May 11, 2017
IIRC there are already some issues with linked libraries anyway, and there is a pretty good solution in #3854 (comment).
So if those are the only two problematic cases, I'd say we should switch over to node module resolution.
angular-automatic-lock-bot commentedon Sep 7, 2019
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.