Docs/review of various affects of type field #475

Activity

1. bmeck

   added

   modules-agendaTo be discussed in a meetingTo be discussed in a meeting

   on Jan 17, 2020
2. hybrist commented on Jan 17, 2020

   

   hybrist

   on Jan 17, 2020

   Contributor

   More actions

   Thanks for collecting that list!

   when loading the main entrypoint of the process or a worker thread it can determine which loader to use: ESM loader (if package.type is "module") vs CJS loader (if type is anything else?

   That sounds like a bug or at least unexpected behavior. The loader for the entry point should be determined by the file format of the entry point, not by the closest package.json#type. E.g. if I'm in type:module and run node foo.cjs, I wouldn't expect the import loader to be involved.

   causes the CJS loader to error for CJS format files that end in .js within that package boundary (not extension-less files?)

   Yep, sounds inconsistent to me. It should complain on all "explicitly ESM or otherwise incompatible files", regardless of the type field and which of the well-known ESM types are present. There are some challenges with how loader hooks could influence format determination though.
3. bmeck commented on Jan 17, 2020

   

   bmeck

   on Jan 17, 2020

   MemberAuthor

   More actions

   That sounds like a bug or at least unexpected behavior. The loader for the entry point should be determined by the file format of the entry point, not by the closest package.json#type. E.g. if I'm in type:module and run node foo.cjs, I wouldn't expect the import loader to be involved.

   It is if a .cjs or .mjs is seen, but the algorithm is actually a bit more complex to reason about than just that, see shouldUseESMLoader's impl

   👍React with 👍1Reacted by Jan Olaf Martin
4. GeoffreyBooth commented on Jan 17, 2020

   

   GeoffreyBooth

   on Jan 17, 2020

   Member

   More actions

   • manipulates format resolution within its package boundary

     • .js and extension-less files in particular
     • also .node

   For .js and extensionless this was the intended behavior, though I think we should talk about whether extensionless files should be supported. I think that kind of slipped in without much consideration.

   .node should be unaffected by "type". Whether import works or doesn’t work for .node files is not something I think we’ve decided; the docs say “An import statement can reference an ES module or a CommonJS module. Other file types such as JSON or Native modules are not supported. For those, use module.createRequire().” So either the docs are wrong or the implementation is wrong, but for sure the "type" field should have no effect on whether import of .node succeeds.

   • causes the CJS loader to error for CJS format files that end in .js within that package boundary (not extension-less files?)

   Just as require('./file.mjs') throws, so should require('./file.js') under type: module since those .js files are defined as being ESM/equivalent to .mjs files. Also require('extensionless') should also throw under type: module.
5. MylesBorins

   added

   Help Wanted

   and removed

   modules-agendaTo be discussed in a meetingTo be discussed in a meeting

   on Feb 12, 2020
6. MylesBorins commented on Feb 12, 2020

   

   MylesBorins

   on Feb 12, 2020

   Contributor

   More actions

   removing the modules-agenda label for now. Please feel free to re-add