This repository was archived by the owner on Apr 16, 2020. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 16, 2020. It is now read-only.
Document behavior of ESM packages that lack main field #73
Description
Example package.json:
{
"name": "foo-bar",
"type": "module"
}Assuming index.js exists, what is the expected behavior of import something from 'foo-bar'? Is this expected to throw a resolve error due to "type": "module" as would happen trying to import from a directory? If "type": "module" where not specified (foo-bar is CJS) would the import statement follow the CJS resolution rules and find index.js?
I thought of this looking at #72, thinking about expected behavior when specifying "exports": {} without main. It seems like this could be uses to provide CLI only packages that intentionally do not provide an API.
Activity
ljharb commentedon Jul 4, 2019
In CJS, omitting a main and an index.js makes your package not requirable. I’d expect the same for ESM.
coreyfarrell commentedon Jul 4, 2019
My question is about omitting main but providing an index.js. I'd expect this to fail to resolve when the package type is
module?hybrist commentedon Jul 4, 2019
I would assume that ESM defaults to main being
./index(or./index.js). The side effect of./indexwould be that only CJS files would work (or an extensionless file in the case above... maybe?).hybrist commentedon Jul 4, 2019
I'd love to define
mainin terms of exports. In which case settingmainto an empty array or null would be perfectly valid once that syntax is supported in exports. And it would cleanly prevent an import of the package with a more meaningful error than "module not found".ljharb commentedon Jul 4, 2019
I would expect it to work, with an index.mjs as well.
hybrist commentedon Jul 4, 2019
With extension resolution magic turned on - yes. Without - I wouldn't expect
index.mjsto work in the case above.ljharb commentedon Jul 4, 2019
In ESM even without extension resolution, I’d expect a literal index.mjs to work.
coreyfarrell commentedon Sep 10, 2019
See https://nodejs.org/dist/latest/docs/api/modules.html#modules_all_together, specifically LOAD_AS_DIRECTORY.
If "main" is a falsy value, GOTO 2.which is doesLOAD_INDEX(x). So ifmainis falsy I'd expect ESM to fail here unless the target is a CJS module. An edge case is what happens ifmainis falsy andtype: moduleis set butindex.cjs,index.jsonorindex.nodeexist.IMO https://nodejs.org/dist/latest/docs/api/esm.html#esm_package_entry_points should be explicit about what happens when
mainis not specified. The edge cases I can think of:type !== 'module'- use CJS resolution algorithmtype === 'module'andindex.cjs,index.jsonorindex.nodeexist - use CJS resolution algorithm but excluding extension.js?Also noticed while looking at this https://nodejs.org/dist/latest/docs/api/modules.html#modules_all_together
LOAD_INDEXandLOAD_AS_FILElist.js,.jsonand.nodeextensions. Should.cjsbe listed here, and if so what priority does it have? Or is.cjsonly resolved when--experimental-modulesis enabled?Another related edge case is what happens when an in-package directory contains an
index.cjs. Shouldimport './some-directory';find./some-directory/index.cjs?