node

Does GitHub discussions fill those requirements reasonably? https://docs.github.com/en/discussions An example of this - https://github.com/nodejs/node/discussions

V8 has such a lax approach to memory management that I sometimes wish I could drop support for everything but Firefox. For example, Promise.race() leaks memory in V8: https://github.com/nodejs/node/issues/17469#issuecomment-685... Another issue I ran into recently is that `Symbol.for(str)` will cause the entirety of `str` to be allocated forever in Chromium, but not in Firefox. (It's inevitable that `Symbol.for()` will have some memory impact, as a global allocation, but it's possible to mitigate it somewhat.) IMO it's too bad that the effort to create a Node-alike driven by Spidermonkey instead of V8 never got anywhere.

contents:read to contents:write is a big deal! Just to pick out a random widely used project, nodejs [1] has a number of unsigned commits to the main branch. Their commits could have been tampered with during this timeframe. What about release artifacts? [1]: https://github.com/nodejs/node/commits/main

> You also cannot pre-initialize v8 as far as I know You can create a snapshot/image with V8 to reduce startup times (https://v8.dev/blog/custom-startup-snapshots). Node already does this for some of its core libraries (https://github.com/nodejs/node/issues/17058). There are plans to expose this functionality to users so that any application and libraries can be snapshotted (https://github.com/nodejs/node/issues/35711).

https://github.com/nodejs/node/issues/35711 Node's working on it.

Of course, using a bundler means you'll face several other unpleasant realities. Like - what about tests, how do they run - source maps support in node being 3rd party and unbearably slow for any medium sized project - edit: this has been fixed somewhat recently https://nodejs.medium.com/source-maps-in-node-js-482872b56116 - only the 3rd party bit, not the slowness bit https://github.com/nodejs/node/issues/41541 - also applicable when not bundling, albiet fewer reprcutions to turning off source maps - poor native (C++) modules support in bundlers - modules with really dynamic `require` statements being supported at varying levels by varying bundlers

Looks like it works quite similarly as in Deno. A notable difference is that it does not cache the imports locally. > Modules, when loaded, are stored in memory but not on disk. This means that every time you restart your node application, it will download the files again. Found some discussion about it, and it seems caching is being considered (possibly in a web_modules folder). https://github.com/nodejs/node/discussions/36430#discussionc...

Right, sorry. My understanding was that dynamic imports were a separate conversation, and they're not part of this effort at the very least: https://github.com/nodejs/node/pull/36328#issuecomment-73590... ---- That being said, yes, if there are plans to support dynamic imports, then literally all of the reassurances people have been giving me about pinning and fetching dependencies ahead of time and having tools to find out-of-date dependencies -- none of that works at all if dynamic imports are supported, you're completely correct. Deno does support dynamic imports, but I have always understood that they use a separate system and are handled/installed differently? I might be wrong about that though, I haven't worked with Deno closely enough to be really confident about its internals.

In terms of feedback, there's an issue thread here covering some points already: https://github.com/nodejs/node/issues/41920

Manually auditing an update of potentially hundreds of packages when package-lock.json gets regenerated is so challenging that many projects won't do it — and for those projects, the cryptographic hashes offer limited value. To make industry-wide improvements, we need to share resources for auditing of packages. There are many such endeavors underway at various stages of maturity. But this feature doesn't move that ball forwards. From the comments: https://github.com/nodejs/node/pull/36328#issuecomment-73603... > It is insecure because there is no signature of the original file. Anybody that can take control of a domain name can take control of a server. Downloaded arbitrary code can't be added to a pool of pre-validated packages, except insofar as you control the server and only make pre-validated packages available on it exclusively t