4 ms·

With regards to bower components, it's typically a good idea to leave the folder in your repo: http://stackoverflow.com/questions/22327758/should-bower-componen

With regards to bower components, it's typically a good idea to leave the folder in your repo: http://stackoverflow.com/questions/22327758/should-bower-components-be-gitignored http://stackoverflow.com/questions/22327758/should-bower-com...

wavefunction 11y ago
I would rather just leave bower.json in the repo. What's the point of bower if you're including the /bower_components folder? edit before someone snarks about rtfa, I did. I disagree. What is the point of bower if you're checking in components.
- dnbdnbdnb 11y ago
  If you're doing something more than a pet/toy project then there are plenty of reasons why you would want to check in components.
- cdcarter 11y ago
  You still get easy control of upgrades, new installs, etc. The tool is there when you want it, instead of on every new clone.
- jakejake 11y ago
  The biggest reason is in case the original source goes away (the author removes a particular version for example). A lesser reason is to make it easier for others to get up and running without needing the build tools. I tend to leave them out if it's a personal, open-source project. For a commercial project I tend to check them in.
  - wavefunction 11y ago
    I guess if that were the case I'd want to package the dependency with my code. I feel like I'm either providing my app with a dependency framework for people to build or I'm providing a packaged product to the public. I suppose you can use the same public repo for both purposes but I would prefer to separate the two functionally.
EvanPlaice 11y ago
Just another example of why Bower is on the path to go the way of the dodo. When ES6 rolls out with System.js (ie polyfills exist now). Javascript will have native support for modules. In addition, JSPM will replace Bower as the tool-of-choice for managing client-side javascript dependencies. Bower was a good 'stepping stone' for an ecosystem of broken module management. Fortunately, module support is improving.

wavefunction 11y ago

I would rather just leave bower.json in the repo. What's the point of bower if you're including the /bower_components folder? edit before someone snarks about rtfa, I did. I disagree. What is the point of bower if you're checking in components.

dnbdnbdnb 11y ago
If you're doing something more than a pet/toy project then there are plenty of reasons why you would want to check in components.
cdcarter 11y ago
You still get easy control of upgrades, new installs, etc. The tool is there when you want it, instead of on every new clone.
jakejake 11y ago
The biggest reason is in case the original source goes away (the author removes a particular version for example). A lesser reason is to make it easier for others to get up and running without needing the build tools. I tend to leave them out if it's a personal, open-source project. For a commercial project I tend to check them in.
- wavefunction 11y ago
  I guess if that were the case I'd want to package the dependency with my code. I feel like I'm either providing my app with a dependency framework for people to build or I'm providing a packaged product to the public. I suppose you can use the same public repo for both purposes but I would prefer to separate the two functionally.

EvanPlaice 11y ago

Just another example of why Bower is on the path to go the way of the dodo. When ES6 rolls out with System.js (ie polyfills exist now). Javascript will have native support for modules. In addition, JSPM will replace Bower as the tool-of-choice for managing client-side javascript dependencies. Bower was a good 'stepping stone' for an ecosystem of broken module management. Fortunately, module support is improving.