SBOM doesn't make sense at this level usually since the things being published lists constraints when installed locally and not locked/pinned versions. Some executables distributed on npm do provide lockfiles but those aren't SBOMs. You cannot really have an SBOM of something with unknown transitive dependencies. There are also disagreements on which SBOM would make sense here as multiple are in play.

> Some executables distributed on npm do provide lockfiles but those aren't SBOMs

Not entirely sure what this sentence means (some executables?), NPM generates lockfiles and, while lockfiles are not SPDX/CycloneDX equivalent, the overlap in intent and content is strong. SBOM makes just as much sense at this level as the existing lockfile generation mechanism.

People are always asking for code signing, really curious to see how they react to this one.

Agreed - people have wanted this feature on npm for a very long time. But code signing has it's limits, as the post mentions. Still, it's a valuable tool and there's no reason not to do it.

incorrect. `await` is a reserved word only in async contexts, the UI thread event loop still runs while `await`ing.

If you run an await as a first thing in the top-level, you have nothing in the event loop to run. Await blocks everything after itself, and that is very dangerous if done on the top-level.

In that script, yes. But in JavaScript you can have multiple scripts :)

> in JavaScript you can have multiple scripts

You mean, you can embed multiple script elements in HTML? Yes. But allowing global await in ES spec means also enabling it in node.

or you could just do `import('a'); import('b');` to load `a` and `b` in parallel

top level await is only possible in grammar w/ `await` as a reserved word. This is limited to Modules (type=module) and async functions. You can't put it in your click handler or random Script like the examples you gave.

I wasn't aware of that restriction. That makes sense. Thanks for the info.

`await` allows the event loop/job queue to run while waiting. However, while using `import` declarations, your module will not run until all imports have completed; this means that your module will be suspended while the dependency awaits.

If your app is shipped as a single bundle this means your entry point would be unable to run anything while dependencies are awaiting if you use `import` declarations. If your app places runtime dependent imports into a dynamic import like using `import()` as a function, it would not be suspended while waiting.

Exactly correct. But note that

> your entry point would be unable to run anything while dependencies are awaiting

is very different from the situation with synchronous I/O (in a single-threaded environment).

With sync I/O, not only is your entry point unable to do anything (which is what it chose to do, by using `import` instead of `import()`), your entire app is unable to do anything! So other entry points are also blocked.

Even worse, since sync I/O blocks the event loop, it prevents the user from interacting with your web page or Node app---e.g. scrolling, clicking links, pressing Ctrl+C to exit, and so on.

ES2015 did not include a loader specification, only a module specification. https://github.com/nodejs/node-eps/blob/master/002-es6-modul... is the interop that will be present for node but it is outside of JS spec itself.

https://github.com/nodejs/node-eps/blob/master/002-es6-modul... was merged today; v8 C++ API for node to truly support it has not been implemented yet, should be in next LTS at current pace (next year).

Wow, a new extension for ES modules? That seems really unfortunate.

Why can't node parse a file to detect if it's a module? The presence of a top-level import or export means it's a module. If it's not, then the parsed file can be kept if the file is also in strict mode. If it's sloppy, it'll have to be re-parsed. Seems like a small penalty if the goal is to enable migration.

Also, why worry about ES modules importing Common JS? Just disallow that and let projects migrate to ES modules bottom-up. Then you don't have to worry about executing a Common JS module to determine what its exports are or circular dependency problems.

There is a pretty epic thread that I suggest you just read the tail end of https://github.com/nodejs/node-eps/pull/3#issuecomment-21476... . Basically we tried detection via source code as the first proposal; ambiguities at runtime that do not throw errors make it absolutely impossible to do safely, performance problems, and tooling integration problems.

Subjective, but .mjs just sounds horrid..

We looked at several alternative extensions and it was the least egregious of them: https://github.com/nodejs/node-eps/blob/master/002-es6-modul...

Vote was at: https://github.com/nodejs/node/issues/5648

const can be used to denote that a reference to the variable is being passed around and should not change for the lifetime of a scope.

    function f() {
      const queue = [];
      consumer(queue);
      return queue;
    }

It could be important to note that removing const has benign effect, but that it is there to ensure a programmer does not change the value of queue between `consumer(queue)` and `return queue`. Easily reasoned about, but extra safeguards from introducing bugs is always nice.

I'm not sure I quite understand your point - while it's true that the variable called queue won't be reassigned, const would still allow elements and properties to be added to queue.

const is not about immutability in JS.

I know that - but the previous comment made it sound as though it did mean immutability.

Ironically enough, but your example shows where const is shouldn't be used as guarantee of immutability: https://t.co/JIQozGe7Md

Isn't that a typical "corner case" in the understanding of dynamic languages bindings ? I think I've seen the same question pop about python. The array binding is constant, its content isn't.

if value of constant can be changed, it's not constant. In my understanding. And by Wikipedia: http://en.wikipedia.org/wiki/Constant_(computer_programming)

That's typical computer lingo / semantic issue. the `const` mean shallow/pointer constant, not deep/structurally constant.

const is not about immutability in JS.

I guess you can say that they are there to allow the compiler to check the intent of the programmer.