bmeck

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.

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

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

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

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.

`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.

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...

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.

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).

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

const is not about immutability in JS.

const is not about immutability in JS.

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.

Once again, these limitations are not with Windows itself (see all the C++ Unicode file functions / file longpaths). In general Node supports long paths just fine (you can watch `npm` write past the 260 [wtf?] char limit). The limitation is in other programs trying to respect MAXPATH even when they should be moving to Unicode functions for compatibility reasons / lack of knowledge. It should be noted that compatibility breaks not just from long paths causing errors, but automatic file expansion does not occur on long paths. So we get into even more special snowflake situations where sometimes files with expansions work with older functions but not with newer ones.

But the fact that Unicode functions don't expand adds an interesting problem for us; the MAXPATH respecting (and outdated) _A filesystem functions can cause a collision for non-expanded paths we get to fun things where you can have different FILE objects if you use old _A functions vs _W functions. The inverse is also true where you can collide by moving from _W to _A.

So! If we do start using old _A functions we actually can cause problems by directing to new files that would cause expansion because of file expansion being turned on.

* https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

* https://msdn.microsoft.com/en-us/library/ms813802.aspx

PS. Don't get me started on FS permissions...

Node uses the Unicode functions so no need, but lots of tools in windows break (cmd.exe notably) so things like child processes don't work on long filepaths. You can actually watch `npm` write to files past the limit by using the Unicode functions, but trying to access them via child processes generally fails (and things like IDEs can't see them). The other problem is that using the longer paths turns of filepath expansion.

* https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...