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

main vs. debug, etc. #31

Closed
dougmoscrop opened this issue May 30, 2014 · 1 comment
Closed

main vs. debug, etc. #31

dougmoscrop opened this issue May 30, 2014 · 1 comment

Comments

@dougmoscrop
Copy link

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.

@sheerun
Copy link
Contributor

sheerun commented Apr 1, 2016

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.

@sheerun sheerun closed this as completed Apr 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants