`main` should be a single entry point about spec HOT 21 CLOSED

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.

from spec.

+1 on useless. Main should facilitate requiring in modules.
On Apr 19, 2014 2:39 AM, "Adam Stankiewicz" [email protected]
wrote:

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 sprockets, we require it in
foobar.scss manifest file.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-40857422
.

from spec.

@KidkArolis @necolas Then how do you know which file is main entry for css?

from spec.

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.

from spec.

Then how do you know which file is main entry for css?

Unless Bower wants to make it a requirement that you use @import and it will inline for you, this concept doesn't exist in CSS.

from spec.

@necolas Yes it does, the order of CSS matters.

from spec.

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 main to removing it at all. Would you like it? I doubt.

from spec.

@josh Probably can confirm the css entry in main is crucial for sprockets integration.

from spec.

main for css (or any other extension) has been implemented in Sprockets for quite some time and is working great.

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.

from spec.

@josh This issue is about removing array main from bower.json, not sprockets.

from spec.

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.

from spec.

I added this topic to our next IRC meeting on Monday. Maybe you want to come.

from spec.

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 main [string|array]: The primary endpoints of your package.

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
This specifies 2 different files as main, wouldn't tools like rails-assets include both of those files, which is undesired?

https://github.com/rstacruz/nprogress/blob/master/bower.json#L12
Here only a js entry point is specified even though this lib also has a stylesheet. That is specified in styles in this case.

https://github.com/tildeio/rsvp.js/blob/master/bower.json#L9
Here the main points to a globals version of rsvp, but what about the amd or cjs main.

https://github.com/mout/mout/blob/master/bower.json#L4
Here the main is a directory.

https://github.com/blueimp/jQuery-File-Upload/blob/master/bower.json#L55-L73
Here the main is all of the files of the library including .. vendored dependencies..

I suppose it's not an issue with main alone. But overall, I wish bower encouraged better interoperability in tools and between libraries.

from spec.

@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.

from spec.

I'd be happy with deprecating main and introducing some new field like entrypoints or loadpaths or assets though. It's up to discussion.

from spec.

"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

On Apr 19, 2014, at 2:28 PM, Adam Stankiewicz [email protected] wrote:

I'd be happy with deprecating main and introducing some new field like entrypoints or loadpaths or assets though. It's up to discussion.

—
Reply to this email directly or view it on GitHub.

from spec.

@rpflorence - not bad.
The only thing I disagree with is moduleType - I think it's incorrect to push the effort of handling all of the module formats to the library authors. It's wasting time of library authors, they need to understand all module formats to support them correctly, etc.. I think with moduleType there's an assumption that only the overlapping subset of all module format functionality can be used in bower components. If that's the case - why not just use one module format and have tools for integrating it into everyone's projects. That would make things massively simpler. For example, only allow publishing CJS or ES6 (doesn't matter which one) anonymous modules to bower and have a package.json entry for specifiying the name of the global variable like global: $ for supporting old style js libs. Bower could then even itself convert between the different module formats after installing the components.

from spec.

You would have to delete the entire bower registry and start over if you start enforcing modules.

Sent from my iPhone

On Apr 19, 2014, at 3:27 PM, Karolis Narkevicius [email protected] wrote:

@rpflorence - not bad.
The only thing I disagree with is moduleType - I think it's incorrect to push the effort of handling all of the module formats to the library authors. It's wasting time of library authors, they need to understand all module formats to support them correctly, etc.. I think with moduleType there's an assumption that only the overlapping subset of all module format functionality can be used in bower components. If that's the case - why not just use one module format and have tools for integrating it into everyone's projects. That would make things massively simpler. For example, only allow publishing CJS or ES6 (doesn't matter which one) anonymous modules to bower and have a package.json entry for specifiying the name of the global variable like global: $ for supporting old style js libs. Bower could then even itself convert between the different module formats after installing the components.

—
Reply to this email directly or view it on GitHub.

from spec.

We could migrate everything over time.
On Apr 19, 2014 10:53 PM, "Ryan Florence" [email protected] wrote:

You would have to delete the entire bower registry and start over if you
start enforcing modules.

Sent from my iPhone

On Apr 19, 2014, at 3:27 PM, Karolis Narkevicius <
[email protected]> wrote:

@rpflorence - not bad.
The only thing I disagree with is moduleType - I think it's incorrect to
push the effort of handling all of the module formats to the library
authors. It's wasting time of library authors, they need to understand all
module formats to support them correctly, etc.. I think with moduleType
there's an assumption that only the overlapping subset of all module format
functionality can be used in bower components. If that's the case - why not
just use one module format and have tools for integrating it into
everyone's projects. That would make things massively simpler. For example,
only allow publishing CJS or ES6 (doesn't matter which one) anonymous
modules to bower and have a package.json entry for specifiying the name of
the global variable like global: $ for supporting old style js libs. Bower
could then even itself convert between the different module formats after
installing the components.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-40881704
.

from spec.

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

from spec.

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 require('./bower_components/foo/dist/foo'), i can simply write require('./bower_components/foo'). when building for a browser, browserify is a nice build tool that honors this convention.

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 @import "./bower_components/foo" (instead of the messier @import "./bower_components/foo/dist/foo.css").

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

from spec.