Node.js Foundation Modules Team Meeting 2019-04-24 #317

Activity

1. GeoffreyBooth commented on Apr 24, 2019

   

   GeoffreyBooth

   on Apr 24, 2019

   Member

   More actions

   I didn’t think we were still debating if we should support dual ESM/CommonJS packages, but if we are, there was discussion in the import file resolution proposal repo in GeoffreyBooth/node-import-file-specifier-resolution-proposal#1 and GeoffreyBooth/node-import-file-specifier-resolution-proposal#11 that led to this text:

   Dual instantiation

   The ESM and CommonJS interpretations of a module have independent storage. The same source module may be loaded as both an ESM version and a CommonJS version in the same application, in which case the module will be evaluated twice (once for each parse goal) and the resulting instances will never have the same identity. This means that whilst import and import() may return a CommonJS exports value for a module whose interpretation is confirmed to be CommonJS, require() will never return the ESM namespace object for a module whose interpretation is ESM.

   Applications that avoid require() and only rely on Node’s interpretation of a module, via import and import(), will never trigger simultaneous instantiation of both versions. With this proposal, the only way to encounter this dual-instantiation scenario is if some part of the application uses import/import() to load a module and some other part of the application overrides Node’s interpretation by using require() or [module.createRequireFromPath][nodejs-docs-modules-create-require-from-path] to load that same module.

   The choice to allow dual-instantiation was made to provide well-defined deterministic behaviour. Alternative behaviours, such as throwing a runtime exception upon encountering the scenario, were deemed brittle and likely to cause user frustration. Nevertheless, dual instantiation is not an encouraged pattern. Users should ideally avoid dual-instantiation by migrating consumers away from require to use import or import().

   It took me a while to find this; if people don’t mind, I’d like to migrate that repo’s discussions and final output .md file into this repo so that this history is easier to find in a search.
2. jdalton commented on Apr 24, 2019

   

   jdalton

   on Apr 24, 2019

   Member

   More actions

   (I may be late to the meeting, I approved #311)
3. MylesBorins

   added a commit that references this issue on Apr 26, 2019

   doc: 2019-04-24 notes

   ...

   86d5ae2
4. MylesBorins

   closed this as completedon Apr 26, 2019
5. MylesBorins

   added a commit that references this issue on May 8, 2019

   doc: 2019-04-24 notes (#321)

   ...

   590da15