No magic index.js about spec HOT 9 CLOSED

This seems like a sensible objection, does this mean bower will throw an error/refuse to register a package that does not provide a main.

Being strict from the start and then loosening the rules if they end up being too strict is easier then being loose at the start and then trying to tighten them up.

from spec.

You definitely should not need to have a main. Components that have many optional modules may not have any sort of "base" requirement. See bootstrap, rails-behaviors.

What is the action item here. index.js is not currently mentioned at all in the spec?

from spec.

To be clear. This is for components containing JS.

This seems like a sensible objection, does this mean bower will throw an error/refuse to register a package that does not provide a main.

We can't do that as many components don't have JS.

My point is for Bower to not try to find an index.js if main isn't specified. As this is a wasted system call and logical overhead for the user.

from spec.

You definitely should not need to have a main. Components that have many optional modules may not have any sort of "base" requirement. See bootstrap, rails-behaviors.

So you would include them by doing

const dropdown = require("bootstrap/js/dropdown");

I guess...

We can't do that as many components don't have JS.

True. I'm seeing everything through the prism of JS because ideally I'd want bower to be the base for a development toolset that allows you to do bower install and within a development webpage/workbench that you use to the develop the package/component that you did bower install within you could instantly start doing require("resource") and it would be available on a browser refresh.

Manually adding script tags doesn't scale for large single page applications made up of tens of components. So something like bower and a tool like browserify that understands ES6 modules and bower packages is the best solution.

Hence my feeling that the more guarantees a bower package can provide the more the toolset can rely on conventions and be simple to develop/understand/develop with.

from spec.

Also relevant: http://blog.izs.me/post/44149270867/why-no-directories-lib-in-node-the-less-snarky

from spec.

Interesting blog, so the take home messages appears to be no magic in bower.

from spec.

I agree with non spec'ing index.js, but rehashing izs's opinion doesn't really apply to our situation.

bower isn't node.js. node.js is built on the assumption everyone can write and maintain this tiny little single file dependencies. This is not the case for the frontend landscape where components can have many parts and many subresources. bootstrap isn't going to create 100 repositories for every js file, css file, or image file.

from spec.

There can be a degree of modularity. Doesn't have to be either Bootstrap or your version.

Keep in mind that we are architecting Bower for the future, not the awful monolithic present. The point is that your thing should do one thing and do it well.

bootstrap isn't going to create 100 repositories for every js file, css file, or image file.

Of course not, but with Web Components it should split the widgets up into self-contained reusable components.

from spec.

Closing as I disagree with 4 months ago @sindresorhus.

from spec.