-
Notifications
You must be signed in to change notification settings - Fork 140
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
should be a single entry point
#20
Comments
It's certainly not useless. We use it at http://rails-assets.org to build proper manifests for sprockets. For example if dist/css/foobar.css is in main, we require it in foobar.scss manifest file. |
+1 on useless. Main should facilitate requiring in modules.
|
@KidkArolis @necolas Then how do you know which file is main entry for css? |
I rely on main in my build processes. It's not useless, it's just hard to define as Bower can be used for different kinds of modules. |
Unless Bower wants to make it a requirement that you use |
@necolas Yes it does, the order of CSS matters. |
Bower doesn't have anything to do with inlining. It's other tools that use main entry, like grunt. There are not only javascript components that use bower. Bower is ought to be platform-agnostic. You can't just blow off other environments because you don't use them. I just told you, the main entry of css is very crucial for tools like rails-assets.org or sprockets. Without it they don't know what files to include if someone wants some css components in project. Without main entry for css, you need to manually find main css file for every component and every its dependency. It's not useless. I can only compare removing css file from |
@josh Probably can confirm the css entry in |
https://github.com/jquery/qunit/blob/master/bower.json#L4-L7 @sheerun don't worry, Sprocket is never going to pull support for main Array. |
@josh This issue is about removing array main from bower.json, not sprockets. |
I think this is pretty unlikely given the fact that its already implemented and it would be a backwards incompatible change. Also, we're lacking a core editor of the bower spec right now. Nothing but clarification changes have been made in many months. |
I added this topic to our next IRC meeting on Monday. Maybe you want to come. |
I'm not against supporting CSS. Let's figure out a nice way of handling css only packages, or js packages with css and try to specify how to do that. My problem with bower's main is that it's way underspecified. Just based on this thread we seem to disagree about what should go and not go into main - that's because it's not specified well with Everyone interprets main in all kind of inconsistent ways which means bower packages can't be easily consumed. And most importantly they can't easily depend on each other. For example: https://github.com/uken/newrelic-timing/blob/master/bower.json#L9 https://github.com/rstacruz/nprogress/blob/master/bower.json#L12 https://github.com/tildeio/rsvp.js/blob/master/bower.json#L9 https://github.com/mout/mout/blob/master/bower.json#L4 https://github.com/blueimp/jQuery-File-Upload/blob/master/bower.json#L55-L73 I suppose it's not an issue with |
@KidkArolis Thanks for providing those examples. Sure, main is underspecified, or rather it's hard to guess what's its purpose without reading bower.json spec (what I guess most people don't do). There are other issues on this repo that provide different solutions. I'm just talking about this one, and it doesn't solve the problem in any way and breaks backward compatibility. There are about 5 different issues and solutions about main, I'm trying to clean them up. I think this concrete solution is wrong, and this issue should be closed. |
I'd be happy with deprecating |
"main" for js, "moduleType" needs the ability to override main, introduce "assets" key and hang CSS, templates, fonts etc from there. How is this a bad plan? Sent from my iPhone
|
@rpflorence - not bad. |
You would have to delete the entire bower registry and start over if you start enforcing modules. Sent from my iPhone
|
We could migrate everything over time.
|
To be completely clear: main can be defined single entry point, but at the same time needs to be deprecated and replaced by something else that has at least support for css. See #6 |
it's a mistake to allow multiple entry points (per language), since that creates ambiguity when consuming a module. eg. say i use bower to install a module called foo. foo contains a package.json with a "main" field. this lets me consume foo without needing knowledge of foo's internal file structure. the "main" field provides a normalized interface to consume modules. so instead of we can do the same thing for the main css file, so with appropriate tooling can consume a module's css without having knowledge of the module's internals. this could look like so i propose a slight modification to the above: bower.json: {
"name": "foo",
"version": "1.2.3",
"main": "./dist/foo.js",
"mainCss": "./dist/foo.css",
...
} cross posted from my comment here for visibility |
main
is currently kind of useless. i'd suggest using it as the main entry point into a component's JS.The text was updated successfully, but these errors were encountered: