Skip to content
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

using npm package management #173

Closed
joshikeerti opened this issue Mar 19, 2015 · 12 comments
Closed

using npm package management #173

joshikeerti opened this issue Mar 19, 2015 · 12 comments

Comments

@joshikeerti
Copy link

If I am using some packages from bower and some others from npm. Is it still possible to use wiredep in that case? I don't see any examples of pulling from npm dependencies.

@CWSpear
Copy link
Contributor

CWSpear commented Mar 20, 2015

It may be really hard to resolve dependencies across npm and bower packages (which, may need to happen).

But it would be pretty powerful if we could pull it off! I see a trend as package creators start planning for ES6 modules, they seem to shy away from bower, as the path from ES6 modules to commonJS is a lot cleaner, and that plays very well in the npm ecosystem.

@stephenplusplus
Copy link
Member

Let's start thinking about this more! :)

@eddiemonge
Copy link
Contributor

Would still need to think about things likes html/css/font/image handling but yes!

@CWSpear
Copy link
Contributor

CWSpear commented Jul 9, 2015

I want to add to my comment from March: it looks like Bower has been taking some steps to better plan for ES6 modules. And again, make sure it's clear that I don't think Bower is going anywhere any time soon!

@Sparticuz
Copy link

👍 Why use bower when npm can do the same things? It wouldn't hurt to support both. I've been able to do some hackey things to get it to work, but would prefer it native.

@Grawl
Copy link

Grawl commented Nov 23, 2015

👍 appreciate to

I think it would be good to use bundledDependencies:

Array of package names that will be bundled when publishing the package.

@stephenplusplus
Copy link
Member

I've been spending some more time thinking about this, and I think the biggest challenge we are going to have is with dependency conflicts. Our solution will likely have to be the same as Bower: having a prompt in the CLI help select between versions, and then persisting those preferences in package.json.

The specific scenario requiring that would be:

$ npm install --save aye bee
|_ node_modules/aye/node_modules/bee[@1.0]/index.js
|_ node_modules/aye/index.js
|
|_ node_modules/bee[@2.0]/index.js
<!-- bower:js -->
<script src="node_modules/aye/node_modules/bee[@1.0]/index.js"></script>
<script src="node_modules/aye/index.js"></script>
<script src="node_modules/bee[@2.0]/index.js"></script>
<!-- endbower -->

Since this is browser-land, we'd have to force the user to choose between bee@1 or bee@2. They might be able to get away with that, but it could also break the app.

My questions are:

  1. Is there a better way to do this?
  2. If a user is running an npm without default deduping, when they run wiredep, should we do this for them?
  3. Is wiredep + npm a good combination, or destined for doom? Is there another tool or workflow we should recommend instead?

@Grawl
Copy link

Grawl commented Nov 25, 2015

@stephenplusplus I found gulp-npm-files package and already started some issues to get similar behavior to wiredep: “Select target array of dependencies” and “Documentation?” with general discussion on it.

@sindresorhus
Copy link

If a user is running an npm without default deduping, when they run wiredep, should we do this for them?

Just force the user to use npm@3.
Example message: https://github.com/yeoman/doctor/blob/master/lib/messages/npm-version.twig

@Grawl
Copy link

Grawl commented Dec 23, 2015

@Sparticuz do you have any progress on this?

@eddiemonge
Copy link
Contributor

related to #234

@eddiemonge
Copy link
Contributor

Closing in favor of #234

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants