get rid of package.json "main" field lookup in module loader

[rlidwka]

Related to ES6 modules, #5, and following a lengthy discussion in npm/npm#8222. Obviously, I'm not talking about require() here, changing it would be insane. But since ES6 module loader would be completely different, we might as well consider to get rid of that. That's why:

• the name of the file package.json doesn't make sense anymore with ES6 modules, because it's a CommonJS name
• this file itself conflicts with ASP.NET (Consider renaming package.json in the next major version (3.0) npm/npm#8222), and other package manager for C (can't find the link and "C" keyword is something pretty hard to search for) update: it's clib
• this is an extra disk read each time something is required. Not a lot, but since module loading happens every time on startup, every bit counts
• if we implement it in new loader, it'll become a standard and have to be implemented in all module loaders (e.g. browserify, nexe, etc.), therefore increasing maintenance burden on the entire community
• there is an idea to move all config files in .config (.config/package.json npm/npm#8159), and this implicit dependency in all loaders only makes it harder

Instead of this, I suggest everyone to just use /index.js in ES6 modules. Maybe use /lib/index.js as a fallback (since most of the packages define "main": "lib/index.js" anyway, but I'm not sure if it's worth it.

[boopathi]

👍
but there are many libraries which use,

"main": "<lib-name>.js"

examples:

• https://github.com/jashkenas/underscore/blob/master/package.json#L17
• https://github.com/lodash/lodash/blob/master/package.json#L4
• https://github.com/AmpersandJS/ampersand-collection/blob/master/package.json#L32

Also, just by looking at some other popular libraries on cdnjs, there are many others too which use this pattern for specifying the entry point.

[Qard]

What if a module has multiple entry point files, like node.js and
browser.js for a browserify-supported module? Not sure what I think of
losing the explicit definition of the two entry points.
On May 16, 2015 4:52 PM, "Boopathi Rajaa" [email protected] wrote:

[image: 👍]
but there are many libraries which use,

"main": ".js"

examples:

• https://github.com/jashkenas/underscore/blob/master/package.json#L17

• https://github.com/lodash/lodash/blob/master/package.json#L4

  https://github.com/AmpersandJS/ampersand-collection/blob/master/package.json#L32

Also, just by looking at some other popular libraries on cdnjs, there are
many others too which use this pattern for specifying the entry point.

—
Reply to this email directly or view it on GitHub
#16 (comment).

[rvagg]

yuk, all of my projects have a "main" that's the same as "name" but with a .js at the end, it makes stack traces more interesting and my editor's fuzzy file name matching much more simple, plus this isn't a website and the index.html -> index.js thing is just weird, like using a floppy disk icon to indicate "save"

[boopathi]

@rvagg exactly. I've something similar. Also, for all my modules in a package, I just proxy things in index.js. Too many index.jss open at the same time in the editor just makes things fuzzy.

my-module/index.js is simply just module.exports = require('./my-module').

If possible, does it make sense to have imports that require the file with its name same as the directory name (maybe fallback to index.js or index.js overrides this - either way it should be fine)? But this might further increase that extra disk read mentioned at the top.

[piranna]

I see index.js somewhat similar to init.py in python...