Additional target for NodeJS ES Modules (MJS)

Question

Additional target for NodeJS ES Modules (MJS)

Closed this issue 6 years ago · 14 comments

I was hoping to use import moize from 'moize/es but the target looks like it is umd and not node es modules. Would be nice to have an additional target with .mjs files for import with NodeJS experimental modules.

Answer 1 · 2018-08-09T21:34:53.000Z

The es implementation was written with browser standards in mind. Based on my (admittedly limited) understanding of Node's implementation, it is the same syntax as the es files just with the .mjs file extension, correct?

Answer 2 · 2018-08-09T21:48:34.000Z

As far as I can tell you are correct.

Answer 3 · 2018-08-09T22:00:10.000Z

Cool that makes it easy ... putting together a PR that does a simple copy / rename of the es folder output as part of the build process. Should be up shortly.

The way you'll use it is:

import moize from 'moize/mjs';

Answer 4 · 2018-08-09T22:07:56.000Z

I added the PR if you wanna take a look ... seems pretty straightforward, but a fresh set of eyes is always helpful.

Answer 5 · 2018-08-09T22:19:02.000Z

I renamed the files to test and I got this error. Need to dig into it more and find out why:

SyntaxError: The requested module does not provide an export named 'orderByLru'
at ModuleJob._instantiate (internal/loader/ModuleJob.js:85:17)
at

EDIT: I think micro-memoize is also not set up for nodejs modules. I don't think it is as easy as renaming the files since there are nested dependencies.

Answer 6 · 2018-08-09T22:23:22.000Z

I think I know what it is ... I am specifically importing that function from micro-memoize/es/utils.

Basically, I need to provide the same .mjs enhancement to micro-memoize, publish it, and then modify the import in moize the way I do currently between es and lib to point to micro-memoize/mjs/utils. I may not get to this tonight, but it should be ready in a day or two.

EDIT: come to think of it ... will this work with any external dependencies that aren't Node ESM-compatible? Because I may need to do the same to fast-stringify.

Answer 7 · 2018-08-09T22:25:42.000Z

I renamed those files and it looks like deepEqual (from fast-equals) also is not a proper mjs. This might be more difficult than originally anticipated.

EDIT: It looks like fast-equals is also your module. I'll try renaming those files and see how deep this rabbit hole goes.

Answer 8 · 2018-08-09T22:27:12.000Z

Yeah I just checked ... I think it needs to be .mjs turtles all the way down. Luckily, I own all of these packages (:wink:), so I can definitely add them ... but it may take a few days.

Answer 9 · 2018-08-09T22:29:37.000Z

So if I do the following:
import memoize from 'micro-memoize/mjs';
import { deepEqual, sameValueZeroEqual, shallowEqual } from 'fast-equals/mjs';

And do the rename/folder for those modules, then it loads.
Whenever you get time, it would be awesome!

Answer 10 · 2018-08-09T22:31:09.000Z

Well that is good news ... at least the theory holds!

Alright well then I'll get to work doing this to those other packages, and report back here once ready to check again.

EDIT: In the meantime, you could always just use @std/esm

Answer 11 · 2018-08-09T22:35:11.000Z

Ohh I didn't even know about that. Yeah it does the chore of doing a require (instead of import) and re-exporting. Thanks!

Answer 12 · 2018-08-10T14:20:25.000Z

Alright I've updated all the sub packages, and the build process to use the mjs versions. If you want to check it out, I'd appreciate the feedback.

Answer 13 · 2018-08-13T08:09:29.000Z

Sorry, I am out of town for 3 weeks. I'll check it out and get back to you.

Answer 14 · 2018-08-13T08:10:55.000Z

No worries, I was actually able to verify it myself with a simple test file ... Worked as expected. This change was released as 5.4.0.