[wccrawford]

I'm not convinced that allowing Node to import "code generated at runtime" is actually a good thing. I think it should have to go through the hoops to get loaded, for security reasons.

I like the idea of it mocking the file system for tests, but I feel like that should probably be part of the test suite, not Node.

The example towards the end that stores data in a sqlite provider and then saves it as a JSON file is mind-boggling to me. Especially for a system that's supposed to be about not saving to the disk. Perhaps it's just a bad example, but I'm really trying to figure out how this isn't just adding complexity.

[Normal_gaussian]

    node -e "new Function('console.log(\"hi\")')()"

or more to the point

    node -e "fetch('https://unpkg.com/cowsay/build/cowsay.umd.js').then((r) => r.text()).then(c => new Function(c + 'console.log(exports.say({ text: \"like this\"}))')())"

that one is particularly bad, because umd messes with the global object - so this works

    node -e "fetch('https://unpkg.com/cowsay/build/cowsay.umd.js').then((r) => r.text()).then(c => new Function(c)()).then(() => console.log(exports.say({ text: 'oh no'})))"

[phendrenad2]

Well there you have it.

I had to laugh, because the post you're replying to STRONGLY reminds me of this story, https://news.ycombinator.com/item?id=31778490 , in which some people on the GNOME project objected to thumbnails in the file-open dialog box because it might be a "Security issue" (even though thumbnails were available in the normal file browser, something those commenters probably should have known about, but didn't, but they just had to chime in anyway).

[rendaw]

I can totally believe that, but at the same time I checked that link and didn't see anything about security mentioned.

[TheRealPomax]

But then you go "hang on, doesn't ESM exist?" and you realize that argument 4 isn't even true. You can literally do what this argument says you can't, by creating a blob instead of "writing a temp file" and then importing that using the same dynamic import we've had available since <checks his watch> 2020.

[dfabulich]

A virtual filesystem makes it possible for the ESM you import to statically import other files in the virtual filesystem, which isn't possible by just dynamically importing a blob. Anything your blob module imports has to be updated to dynamically import its dependencies via blobs.

[apatheticonion]

Correct. Especially painful if you use Worker threads or .node files

[notnullorvoid]

There's also a module expression proposal, that would remove the need to use blob imports.

https://github.com/tc39/proposal-module-expressions

[apatheticonion]

As a user of embedded Node.js - I need the ability to package JavaScript into the binary and feed it to Node.js without writing it to disk.

My current flow is to literally embed the JavaScript in the binary, then on start, write the JavaScript code to `/tmp/{random}` and point Node.js to execute the code at that destination.

A virtualized filesystem also allows for a safer "plugin" story for Node.js - where JavaScript plugins can be prevented from accessing the real filesystem.

[bsjshshsb]

Not a Lisp fan?