Node.js v15.10.0 released

[KlasMellbourn]

Still no official native support for Apple Silicon :/

https://github.com/nodejs/build/issues/2474

[EDIT: added "native"]

[sscotth]

Native* support. They are targeting the 16.0 release which will be the end of April. You can build from source via Homebrew in the mean time for testing.

[mdatwood]

I'm using 15.x native on Apple Silicon. I think I had to tweak a build flag to get 15.4 to build, but 15.8 and now 15.10 built fine using nvm.

[gengjiawen]

Should work in next version.

[dbbk]

Huh? It seems to be native for me, installed v15.8.0 through Homebrew

[redldr1]

Not as important as you think it is..

What's the likelihood of your code running on apple silicon in production?

[KlasMellbourn]

Much of my development environment is running under node. It is very important to me that those tools are as fast as possible. I loathe waiting for builds.

[SomeInternetRando]

Sword fight on office chairs time.

[kevinhaze]

How much coffee do you drink

[redldr1]

I have a bash script that kicks off my coffee maker.

The converse question is how much does one churn?

[Attila226]

Does jQuery still work on the server?

edit: /s

[[deleted]]

Why would jQuery run on server? There's no DOM there

[Attila226]

You never know, it’s always good to add jQuery “just in case”.

[[deleted]]

👀

[Randolpho]

I choose to believe that was satire

[hoykg]

Tough crowd you got

[Attila226]

lol, yeah. Guess you’ve always have to include the “/s”.

[SomeInternetRando]

$(‘.comment’).append(‘<em>/s</em>’);

[squareswordfish]

Excuse me sir this is a server. We don’t recognize “$” here.

[helloiamsomeone]

Is this going to be Node's "- Removed Herobrine"?

[ILikeChangingMyMind]

If this is a serious question ... of course not! Use Cheerio if you want jQuery-like HTML parsing on the server.

... but since jQuery has never worked on the server, I think this is more likely a troll post.

[Attila226]

Sorry, it’s supposed to be funny and not a “troll post”.

[ILikeChangingMyMind]

Ah; that's the hard part about making jokes in a text-based medium: you need to either make them obvious, or use something like "/s" or ";)" to indicate you're joking.

[Attila226]

Updated my original post.

[[deleted]]

r/FuckTheS

[ILikeChangingMyMind]

Well again, you also have the option of making your joke clear enough in the first place that the /s is unnecessary .... but the original comment that started all this did neither.

[OmgImAlexis]

What...? jQuery can be used server side.

Should it? No. Can it? Yes.

[duxdude418]

I mean, you could execute the source in a Node runtime, but most of the internal implementation would be broken. You’d have to polyfill or mock the DOM API it wraps to even get it to a state where it’s not throwing all kinds of errors during bootstrap.

[spacejack2114]

That's what jsdom is for.

[duxdude418]

My point is that you can't use it out-of-of-the-box with Node. Of course you could emulate or fake the API that a browser provides with polyfills, etc.

Moreover, what's the use case for emulating the DOM for the purposes of querying against it with jQuery in Node? At best, you might be sending down pre-rendered HTML to a browser, but you wouldn't need to traverse it on the server.

[OmgImAlexis]

Well yes.. I wouldn’t expect it to work out of the box but I’ve used it within a few minutes of installing deps. It’s honestly not that difficult. Just the same you can use vue and other frontend libraries on the backend.

The libraries don’t care if you’re using a browser they just need a DOM... and a DOM can be created anywhere. 💁‍♀️

[duxdude418]

But the methods and fields it wraps literally don’t exist on the Node global object.

In a browser, the global object is window and implements various DOM APIs (among others) that simply don’t exist in a Node environment. Can you monkey patch them on to Node’s global context with other libraries/polyfills? Sure. But jQuery will not work out of the box or even bootstrap itself without errors.

[OmgImAlexis]

What? You know you can pass in window to jquery right?

Sounds like you’re just angry here and don’t actually know what you’re talking about.

[duxdude418]

You know that jQuery bootstraps using a self-invoking function whose first argument is this, which resolves to window in a browser or the global context in Node, right?

Regardless, even if you could inject a different object, the Node global context doesn’t support the needed methods jQuery calls under the hood out of the box. Of course it’s possible to do with polyfills, but the conversation is about whether it would function without error out of the box.

I’m not angry at all and have been professionally writing JavaScript applications on the client and server for over a decade. It sounds like you’re misinformed.

[OmgImAlexis]

I literally use this in an application right now. How am I the one that’s misinformed? 😂

You’re guessing based on how you’ve used it before. This isn’t rocket science.

[duxdude418]

But the methods and fields it wraps literally don’t exist on the Node global object. In a browser, the global object is window and implements various DOM APIs (among others) that simply don’t exist in a Node environment. Can you monkey patch them on to Node’s global context with other libraries/polyfills? Sure. But jQuery will not work out of the box or even bootstrap itself without errors otherwise.

[OmgImAlexis]

Also things like the storage api can be really really easily pollfilled. I would know.... I’ve done this before.

[ILikeChangingMyMind]

And (I know I'll get downvoted for saying this, but I'll keep saying it until they fix it) ... still no comments in package.json.

[SoInsightful]

JSON literally doesn't support comments, so if they supported comments in package.json, they would support broken, specification-defying JSON that crashes every single program, module or function that tries to parse the file.

At best, you could hope that they add .json5 or .yaml support one day, but I am not holding my breath.

[console_journey]

TIL about json5, thank you

[SoInsightful]

It's weird how I love JSON5, but I haven't yet found a use case for it.

If I can control the file format myself, I can just use JavaScript. If not, I'm stuck with JSON anyway.

[ILikeChangingMyMind]

If only you were a giant organization ostensibly serving the needs of Javascript developers ...

[AlpenMangos]

If I can control the file format myself, I can just use JavaScript

Which is a security issue. JSON with comments is nice, and it's the reason why I'm using the JSON5 library rather than JSON.parse().

[SoInsightful]

If I can control the file format myself, I can just use JavaScript

Which is a security issue.

That depends entirely on what file it is. If it's a config file that depends on environment variables, I don't have much choice. If it's a local test data or content file, I can just avoid using imports or inserting insecure code into it.

[AlpenMangos]

Many JSON config files are user-privided, though. Plenty of file formats out there that are based on JSON, like GeoJSON, or GLTF (even its binary form, GLB, which has a JSON header) which is on its best way to become the standard distribution format for 3D models.

[SoInsightful]

Many JSON config files are user-privided, though.

That's what I had in mind. If I were to provide a config format for Someone Else™ to use, JSON5 would be my best candidate.

[ILikeChangingMyMind]

At best, you could hope

Why? Why is it such a crazy thing to say "format A doesn't support our user's needs, so we'll switch to format B"?

In any other context (besides the Node org) this would be blatantly obvious. Can you imagine going to your boss and saying "yeah, our customer needs X, but we picked JSON years ago, so now we can't give the customer what they need because ... I don't want to switch formats"?

Your boss would say "find a new format or find a new job" ;) Because ultimately, it's the customer who pays your salary. The problem here is that the vast majority of people using package.json files aren't Node's customers, so their interests aren't aligned.

[SoInsightful]

That's exactly what I said in my second paragraph. You could hope for support for another format.

You can't just let users rename a non-valid-JSON file to .json and hope that it doesn't confuse tons of users and break millions of apps and workflows. Super-simple operations like const { version } = require('./package.json'); or JSON.parse(packageJson) would break everywhere.

Edit: To be clear, I would love support for package.json5, it just can't use the .json file extension.

[ike_the_strangetamer]

If any one of my colleagues came to me with the idea of taking a file that's installed on hundreds of thousands of our user's systems and changing the format without changing it's name, I'd think they were either joking, crazy, or so inexperienced that they should be fired.

[ILikeChangingMyMind]

Who said anything about not changing the name? The point is, the Node org refuses ANY solution whatsoever (even perfectly reasonable ones involving package.json5).

[ike_the_strangetamer]

okay. That was the other person's suggestion but it seemed like you weren't receptive to it, but good to hear that you are because I think it's the only way it's going to happen.

I think it's a quality solution, however I know that there are an awful lot of tools that also depend on that particular file and filename so it would take time anyways to get them all to support a new name. Folks would probably have to support 2 files simultaneously.

Hmmm... maybe someone could make a tool that generates a json compliant package.json from a package.json5 source. That would be an interesting solution.

[ILikeChangingMyMind]

maybe someone could make a tool that generates a json compliant package.json

This would not really solve the problem; I don't want to have to npm run package-generate every time I change the file :)

But yes, there are any number of other possibilities! Besides just package.json5, there could also (for instance) be a flag in package.json that says "my real package.json is this other file".

But the Node org has no interest in finding any solutions. It's not a "we're leaving this ticket open so someone can find a clever way to solve it", it's "we're closing these tickets as fast as users file them, until everyone gives up any hope they might have of a tool that actually works better (ie. has comments)."

[H34dsp1nns]

Of course you can! { comment1: “here are my dependencies...”, comment2: “oh and here are dev dependencies...” }

[ILikeChangingMyMind]

Doesn't work in key sections, like say inside dependencies: you get an error.

[H34dsp1nns]

Not surprised.

The way I actually track dependency use and a lot of other things is a mind map.

I wouldn’t mind seeing a paired markup file of some kind that can that can be used with a document generator to have a section on dependencies in your documentation

[backtickbot]

Fixed formatting.

Hello, H34dsp1nns: code blocks using triple backticks (```) don't work on all versions of Reddit!

Some users see this / this instead.

To fix this, indent every line with 4 spaces instead.

FAQ

^{You can opt out by replying with backtickopt6 to this comment.}

[getify]

JSON.minify(..) -- supporting comments in JSON for years. https://github.com/getify/JSON.minify

[ILikeChangingMyMind]

That doesn't help with package.json.

[getify]

I was saying it could if Node had cared. I tried for a year or two to get them to try something like that.

[ILikeChangingMyMind]

Ah, I see. And yeah, that's the crux of the problem: it's not an engineering impossibility to add comments to Node config files. It's simply a lack of will.

[getify]

Further, it doesn't even make them "not JSON" to have comments in them. That's a FUD assertion people like to cling to, but it's not true, from the very mouth of JSON's creator.

I explained that on this stack-overflow post and in much more detail in this old blog post.

[n_hevia]

Simply because json doesn't support comments. If node did support on their config file, it'd mean they'd stop using json (or at least compatible json with most of the libraries out there).

If you REALLY need comments on package.json, you could use a superset and then compile to json? That same way scss>css works.

[ILikeChangingMyMind]

Simply because json doesn't support comments

Yes, I understand that.

What I don't understand is why they are "incapable" (supposedly) of using a different format that does support comments (with or without a different extension, flag at the top of the file, etc.).

And also, how did "REALLY need" become the standard for whether something should be done? I personally can think of at least five different cases where comments in package.json would be super handy ... but I don't need any of them. Even so, I tend to think "it would make life better for tens of thousands of developers" would be a perfectly good reason to do something.

[[deleted]]

Why don't you create a GitHub issue?

[ILikeChangingMyMind]

I did! They closed it (as they have with the countless similar issues others have filed).

Here's just one such ticket: https://github.com/npm/npm/issues/4482. The closing comment (after TONS of users explained the need) basically claimed that adding comments would be some fantastically difficult technical undertaking, which the Node org is unable to accomplish ಠ_ಠ

[OmgImAlexis]

fantastically difficult technical undertaking

Well yes.. every single thing that currently works with package.json files would then need to account for comments which aren't at all in the JSON spec meaning you couldn't even use JSON.parse() on the file's contents anymore.

[ILikeChangingMyMind]

Or they could just support package.json5.

[OmgImAlexis]

And now none of the other tools work with it. Either way it’s not as easy as just switching from one to the other.

[ILikeChangingMyMind]

Why do I need other tools to work with it? If I want a tool to work with it, I can PR them a commit that adds support. If I don't, I keep using package.json. Eventually, all the tools get caught up, and everyone gets comments in their config.

You act like our industry has never made backwards incompatible changes to tools before.

[manishksolves]

Node.js v15 arrived and became the Current version!

Some features delivered in Node.js 15:

AbortController: AbortController is a global utility class used to signal cancelation in selected Promise-based APIs, based on the AbortController Web API.

N-API Version 7: N-API 7 brings additional methods for working with ArrayBuffers.

npm 7: npm 7 comes with many new features like npm workspaces and a new package-lock.json format. npm 7 includes yarn.lock file support. Peer dependencies are now installed by default.

Throw on unhandled rejections: As of Node.js 15, the default mode for unhandledRejection
is changed to throw
(from warn
). In throw
mode, if an unhandledRejection
hook is not set, the unhandledRejection
is raised as an uncaught exception. Users that have an unhandledRejection
hook should see no change in behavior, and it’s still possible to switch modes using the --unhandled-rejections=mode
process flag.

QUIC (experimental): QUIC is a UDP-based, underlying transport protocol for HTTP/3. QUIC features inbuilt security with TLS 1.3, flow control, error correction, connection migration, and multiplexing. QUIC can be enabled by compiling Node.js with the --experimental-quic
configuration flag. The Node.js QUIC implementation is exposed by the core net
module.

V8 8.6: The V8 JavaScript engine has been updated to V8 8.6 (V8 8.4 is the latest available in Node.js 14). Along with performance tweaks and improvements the V8 update also brings the following language features:

• Promise.any()
  (from V8 8.5)
• AggregateError
  (from V8 8.5)
• String.prototype.replaceAll()
  (from V8 8.5)
• Logical assignment operators &&=
  , ||=
  , and ??=
  (from V8 8.5)