You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been reading the showdown and other commentary as to what 'main' means, and in addition to the actual nature of main (single entry, array, etc.) is it possible there is an additional "dimension" to consider?
Ember specifies ember.js as their main. But this is the debug version: It's slower, has asserts, logging statements, etc. but they also have ember.prod.js.
(neither are minified - the production one is simply faster)
Should Bower attempt to specify how components might express these configurations? So, in the Ember case, they might have
main: 'ember.prod.js',
debug: 'ember.js'
If Bower did not want to get in to treating debug as a first-class concept, then it could require namespacing them - e.g. alternatives: ...
I use Brunch, and it has a configuration override mechanism. I could foresee my development configuration specifying bower: { configuration: 'debug' } or something to that effect, and the build process would use a simple "if the configuration exists, use that, otherwise fallback to main" resolution policy as it processes each component.
This means that during development I can get the benefits of debug related things, but when I brunch build --production the configuration system would omit the main override (and just use default for everything).
What I'm describing would involve changes on the way Brunch works, of course, but they would only be possible if Bower was tolerant of - or even encouraged -alternative configurations.
The alternative is that I have to mess around with bower overrides, which doesn't really feel appropriate for "build release" vs. "build debug", and I've seen some people wanting to have a shadow bower.json (e.g. bower-debug.json) which doesn't feel right either.
The text was updated successfully, but these errors were encountered:
We clarified main field meaning in bower/spec. I'd rather encourage you to use platform-specific configuration rather than proposing another, generalised environment configuration.
For example you can actually use ember.prod.js for embed projects or NODE_ENV for node projects.
I've been reading the showdown and other commentary as to what 'main' means, and in addition to the actual nature of main (single entry, array, etc.) is it possible there is an additional "dimension" to consider?
Ember specifies
ember.js
as their main. But this is the debug version: It's slower, has asserts, logging statements, etc. but they also haveember.prod.js
.(neither are minified - the production one is simply faster)
Should Bower attempt to specify how components might express these configurations? So, in the Ember case, they might have
If Bower did not want to get in to treating
debug
as a first-class concept, then it could require namespacing them - e.g.alternatives: ...
I use Brunch, and it has a configuration override mechanism. I could foresee my development configuration specifying
bower: { configuration: 'debug' }
or something to that effect, and the build process would use a simple "if the configuration exists, use that, otherwise fallback to main" resolution policy as it processes each component.This means that during development I can get the benefits of debug related things, but when I
brunch build --production
the configuration system would omit the main override (and just use default for everything).What I'm describing would involve changes on the way Brunch works, of course, but they would only be possible if Bower was tolerant of - or even encouraged -alternative configurations.
The alternative is that I have to mess around with bower overrides, which doesn't really feel appropriate for "build release" vs. "build debug", and I've seen some people wanting to have a shadow
bower.json
(e.g.bower-debug.json
) which doesn't feel right either.The text was updated successfully, but these errors were encountered: