Webpack config not finding nested node_modules

[jshcrowthe]

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.

1. Clone the repo: https://github.com/jshcrowthe/ng-cli-nested-node-modules.git
2. Enter the repo dir
3. Run npm install
4. Run ng serve
5. Observe error from ng serve command

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

[clydin]

Unfortunately, yes, it currently doesn't work but a solution is in progress.
Note that everything works with yarn as 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]

@hansl this is the problem we talked about yesterday with Firebase.

[clydin]

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:

• Angular libraries which do not properly use peer dependencies.
• Linked libraries which have their peer dependencies installed via dev dependencies.

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]

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]

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.}