paths Proposal

[josh]

The one line pitch, paths are aliases like main for subassets.

We've discussed this a bunch of times without putting forward any action. This has been on my wishlist for a while. Its definitely a new "feature" unlike main which has actually existed since the beginning.

main serves the majority of packages well that offer a simple single entry point into the package. However, theres a class of packages that want to expose many submodules to the user in a nice way. If you care about the ascetics of paths, you are forced to put all your assets at the root of the package. This is not ideal.

I'll use bootstrap as an example from here on.

{
  "main": "styles/bootstrap.less",
  "paths": {
    "grid.less": "styles/grid.less",
    "modals.less": "styles/modals.less",
    "modals.js": "js/modals.js",
    "scrollspy.js": "js/scrollspy.js",
    "icons.eot": "fonts/glyphicons-halflings-regular.eot"
  }
}

The syntax here is much like RequireJS's paths config. However, we need to be clear about file extensions since we aren't just deal with .js. Heres how grunt-bower-requirejs would interpret this config and autogenerate the following.

requirejs.config({
  baseUrl: './',
  paths: {
    'bootstrap/modals': 'bower_components/bootstrap/js/modals',
    'bootstrap/scrollspy': 'bower_components/bootstrap/js/scrollspy'
  }
});

Resources

• josh/rails-behaviors - I'm forced to put all my files at the root here since I actually want nice requires. Otherwise I'd put my files into lib/ or src/.
• Modernizr - Most of the optional feature detects are under feature-detects. It might be nicer to expose them as modernizr/geolocation etc.

[briandipalma]

+1, much nicer to do

const bootstrapModal = require("bootstrap/modals");

and have modals in a src/ then having them lying at the root of the project.

[sindresorhus]

This is a bad idea. We shouldn't sacrifice explicitly with a minor convenience.

npm has had to fight this many times. I guess this is why you don't reinvent a package-manager.

https://groups.google.com/d/msg/nodejs/kxw_rSqu3AY/iDxNWFplRhIJ

Node programs run on filesystems. Every step of indirection away from
"the file on the filesystem" to "the string in the require()
statement" is a cost. Some of those costs provide some benefit, like
how require("foo") can be either locally in node_modules, or up a
level, so that modules can share dependencies (but don't have to, if
they would conflict). Other costs, like how require("foo/bar") can be
either foo/bar, or foo/bar.js, or foo/bar/index.js, are simply
historical mistakes that seemed like a good idea at the time, but
provide no value, and are now too costly to remove.

[briandipalma]

Good point, indirection does have a cost. I tend to be against it.

Node programs run on filesystems.

That is not true of bower packages though so the cost/benefit analysis might not have the same result for bower packages. There is also a cost to hardcoding the file structure of a package in the requires.

const bootstrapModal = require("src/bootstrap/modals");

Makes for a less flexible package.

[josh]

Its easy for node to say that when the don't have to deal with other asset types. Not ever type of resource can be reference relative internally to the package.

@import "bootstrap/styles/modals";
.button {
  background: url("bootstrap/images/button.png");
}

Package maintainers are highly unlikely to change their structure based on bower.

[sheerun]

Bower can create symlinks for entries in paths. No additional indirection is necessary.

I like this idea, because it provides entry points for assets similar to exports in node.

I guess alternative solution would be "assets_dir" that selects which directory contains assets to be hosted and used by helpers (for example dist folder).