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

add --dev install option for devDependencies, cleaned up #251

Closed
wants to merge 5 commits into from

Conversation

desandro
Copy link
Member

Cleaned up PR for #246 ... all for #80


You can now do bower install --dev or bower install -d and bower will add packages from devDependencies from your project's JSON.

Has basic test. It's fairly simple, extending manager.json.dependencies with manager.json.devDependencies


This does not solve for resolving endpoint devDependencies, i.e.

bower install package-name --dev

@satazor
Copy link
Member

satazor commented Feb 11, 2013

I think we should follow npm regarding the default behaviour of installing dev dependencies.
npm install also installs dev dependencies specified by the package.json, by default.
Having this in mind, bower install should also install dev dependencies specified in the component.json, by default.

What you guys actually think of this behaviour?

@desandro
Copy link
Member Author

Some context https://github.com/isaacs/npm/issues/2799

Typically, if you're running npm install right there in the root of a package, you're developing it, testing it, etc. So, yes, this is intended behavior. Doc patch welcome.

I feel the use case for bower is a bit different. If you're installing stuff, you just want to get it. I feel like the more frequent use case is that you just want the stuff, you're not looking to build documentation or run tests.

See also https://github.com/isaacs/npm/issues/2369 where there's several responses against installing devDependencies by default.

npm works in the opposite fashion, allowing you to pass a --production flag to opt-out of installing devDependencies.

@satazor
Copy link
Member

satazor commented Feb 11, 2013

@desandro Please note that dev dependencies of dependencies would not be installed. Only the project dev dependencies would. I suggested this only to keep consistency with npm. Also the same thing applies here. If you cloned a project, thats because you will work on it, and you will probably need to do something with the dev dependencies.

Still, I see your point and I'm not totally against it.

@satazor
Copy link
Member

satazor commented Feb 11, 2013

Lets see what others think.
//CC @sindresorhus @paulirish @addyosmani @necolas

@sindresorhus
Copy link
Contributor

I like how npm install installs devDependencies by default. You develop a lot more than you do prod. Make it easy for the developer, not the production server.

@desandro
Copy link
Member Author

It took me a while, but I finally get what you're saying. Yes, it makes sense to add devDependencies by default on the project level. So that when you clone a repo, then run bower install, you get all dependencies to build that repo. But when other developers add a component as a dependency - you won't download those devDependencies.

Okay, I think we're in agreement. :)

@satazor
Copy link
Member

satazor commented Feb 14, 2013

@desandro we need to add a test that asserts that dev dependencies of dependencies are not fetched.

@desandro desandro closed this in b7cbd36 Feb 14, 2013
@sindresorhus
Copy link
Contributor

Nice work @desandro 🍰

@MarcelloDiSimone
Copy link

It would be nice to have also an additional 'devDirectory' config option in .bowerrc, so you can optionally keep development dependencies separate from the project related packages. This would really help with automated build scripts to keep them out of the production version.

I know this breaks with the way npm handles development dependencies, but since npm has no configurable directory either, it shouldn't be a big issue.

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

Successfully merging this pull request may close these issues.

None yet

4 participants