René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Proposal for dual ESM/CommonJS packages","articleBody":"@guybedford, @jkrems and I discussed the package dual-ESM/CommonJS case and we have a small proposal, based on the current [ecmascript-modules implementation](https://github.com/nodejs/ecmascript-modules):\r\n\r\n- The `package.json` `\"main\"` field reverts to its prior CommonJS-only use.\r\n\r\n- A new field `\"exports\"` is created that takes a string like `\"./src/index.js\"`. This is the ES module entry point. `\"exports\"` is to `import` what `\"main\"` is to `require`.\r\n\r\nNotes:\r\n\r\n- `\"exports\"` may in the future take an object, preserving design space for the [package exports proposal](https://github.com/jkrems/proposal-pkg-exports).\r\n\r\n- If `\"exports\"` points to a `.js` file and `\"type\": \"module\"` is not set, an error is thrown similar to the “type mismatch” errors (like using `--type=commonjs` with an `.mjs` file). The error would also instruct the user to add `\"type\": \"module\"` to `package.json`. The `\"exports\"` field does not imply `\"type\": \"module\"`.\r\n\r\nAnd that’s it! This should cover the case while preserving design space for future proposals, and for Node potentially switching to ESM by default someday.","author":{"url":"https://github.com/GeoffreyBooth","@type":"Person","name":"GeoffreyBooth"},"datePublished":"2019-02-25T21:58:44.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":87},"url":"https://github.com/273/modules/issues/273"}