Skip to content

Fix for importing Ramda in ESM-compatible nodes#2999

Merged
CrossEye merged 1 commit intoramda:masterfrom
Andarist:add-node-esm-support
Mar 31, 2020
Merged

Fix for importing Ramda in ESM-compatible nodes#2999
CrossEye merged 1 commit intoramda:masterfrom
Andarist:add-node-esm-support

Conversation

@Andarist
Copy link
Copy Markdown
Contributor

closes #2988

This all is quite new in general. node has added support for ESM just recently so keep in mind that I can't guarantee that this covers everything ideally, but I've done the research and some testing and I'm positive about this working correctly. If any problems arise from this - just ping me and I will prepare appropriate fixes (hopefully this won't be necessary though).

@@ -0,0 +1,6 @@
const fs = require('fs');
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've not done this in shell to support Windows contributors.

Copy link
Copy Markdown
Member

@Bradcomp Bradcomp Mar 27, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not on Windows, but I really appreciate this consideration. It helps reduce the barrier to entry for contributing.

"build:es": "cross-env BABEL_ENV=es babel source --out-dir es",
"build:es": "cross-env BABEL_ENV=es babel source --out-dir es && node ./scripts/addModulePackageScope.js",
"build:cjs": "cross-env BABEL_ENV=cjs babel source --out-dir src",
"build:mjs": "cross-env BABEL_ENV=es babel source/index.js --out-file src/index.mjs",
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this was particularly needed and should be even more obsolete thanks to the changes here.

".": {
"require": "./src/index.js",
"import": "./es/index.js",
"default": "./src/index.js"
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"require" and "default" are serving the same purpose - CJS consumers, problem is that there was an experimental version of node@13 which had support for "import" but had no notion of the "require" key, so this "duplication" handles both versions at the same time as that experimental version of node can just fallback to the "default" whereas the new version will match against "require"

"import": "./es/index.js",
"default": "./src/index.js"
},
"./es/": "./es/",
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those are here to allow for "deep" imports like import add from "ramda/es/add.js". This isn't needed per se and you could explore hiding those files entirely through listing all allowed entries in this "exports" field (which could result in things being accessible like this: "ramda/add"), but I've added this for backward compatibility for now.

"bench": "node scripts/benchRunner",
"bookmarklet": "node scripts/bookmarklet",
"build:es": "cross-env BABEL_ENV=es babel source --out-dir es",
"build:es": "cross-env BABEL_ENV=es babel source --out-dir es && node ./scripts/addModulePackageScope.js",
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the type of interpretation is set based on the nearest package.json file, so we can just add a package.json with {"type": "module"} to a directory to make files in that directory being treated as modules even if the root is treated as commonjs (and still use .js for all files!)

@Bradcomp
Copy link
Copy Markdown
Member

This looks really good to me.

I have one concern, and that is that the changes are fairly inscrutable without your fantastic comments. Somebody who isn't already well versed in package.json files wouldn't know why things are set up the way they are.

Is this an issue? Should we look at hacking in some comments?

@Andarist
Copy link
Copy Markdown
Contributor Author

Is this an issue? Should we look at hacking in some comments?

Sure, I can write this down somewhere. Not sure though if package.json itself is the right place to do so 😅 If you want to keep it there I'm OK with that - just let me know where should I put it.

@Bradcomp
Copy link
Copy Markdown
Member

Bradcomp commented Mar 27, 2020

I honestly don't know where we should put it ¯\_(ツ)_/¯

Edit: on second thought, I suppose we can always just point to this PR in the release notes for the next version and it's all explained 😄

Copy link
Copy Markdown
Member

@Bradcomp Bradcomp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:bowtie:

@CrossEye
Copy link
Copy Markdown
Member

CrossEye commented Mar 29, 2020

Anyone understand why GitHub is saying that some checks are incomplete, but that Travis is saying they are complete?

One had failed before for what looked like spurious reasons. I restarted, and it looks fine on Travis, but GitHub is saying otherwise. Any ideas?

Other than that, this looks great to me. I think I would rather point to this pull than try to hack comments into package.json, although I really do wish that commenting JSON were easier to do.

🌿

And thank your once again @Andarist for coming to our rescue. I really should learn more about this material.

@Bradcomp
Copy link
Copy Markdown
Member

@CrossEye Can we just merge anyway since we can still visually verify the CI completed successfully?

@CrossEye
Copy link
Copy Markdown
Member

@Bradcomp: I was planning on giving it two days in case someone who understood what happened with Travis pointed out some flaw I didn't understand. But yes, I think we can merge soon.

@CrossEye CrossEye merged commit 87d90ba into ramda:master Mar 31, 2020
@Andarist
Copy link
Copy Markdown
Contributor Author

If this causes any problem (hopefully not) then please just ping me and i will try to find a fix for it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Problem with ECMAScript modules import in nodejs and browser

3 participants