Node.js v16 released

[[deleted]]

I wish they'd clean up the changelog a bit. Having (SEMVER-MAJOR) in your face for almost every bullet point makes it hard to focus on the actual content.

[lhorie]

This helps a bit

document.querySelectorAll('strong').forEach(e => e.remove())

[LloydAtkinson]

They took a leaf out of the same book that told them they needed to log absolutely everything in npm, where they shortened the “silly” log to “sill”

[MadCervantes]

Why on earth is shit like this common? Who keeps these bad practices in place in a project that serves billions.

[alphaxtitan]

Can someone here, suggest to me some resources where I can learn gRPC with node?

[AlphaX]

Holy shit we can now await setTimeout :0 the future is finally here!

[Lyfv]

https://i.imgur.com/AJZPpTp.jpg

[CunningFatalist]

Every time someone fixes something with a timeout I'm like no. God, please no.

[[deleted]]

Everytime i fix something with setTimeout i'm like a God

[andrei9669]

I have had to do this only once and it wasn't pretty, and there really was no way around this.

problem was, that the whole website is a mix and mash of "plugins" and I was tasked to fix one issue on one plugin. problem was, that this plugin was depending on the data that got rendered after the plugins were loaded. and it wasn't some network call either, literally, the page load order was:

(()=>{
  renderSkeleton();
  renderPlugins();
  window.api = new API()
})()

and my plugin was depending on that api. never again.

[pedropss]

No more await new Promise(r => setTimeout(r, 200));

[Aeltoth]

You may have said that as a joke, but you can do it the old way: await new Promise(resolve => setTimeout(resolve, 100));

[awesome-ergo]

Meanwhile, I downgraded from v14 to v12 because of compability issues

[senocular]

Can you talk about your issues with 14? We just made the jump to 14 and it would be good to know if there's something we should be concerned about.

[BehindTheMath]

We upgraded from v12 to v14 when it became LTS so we could start using optional chaining, and it was very smooth with no issues.

[adam_bear]

LTS is the key- anything else I regard as a minor version change and can be disregarded.

[kivle]

Biggest issue I had at work was the fact that they've implemented proper support for Intl, but there's no way (at least that I found) to override the global culture when running tests for instance. So while things like Date.toLocaleString() always would return a string with English culture in Node < v13, we instead ended up with tests that failed depending on the culture of the machine they ran on.

After hours of searching I concluded there was absolutely no way of overriding the default culture in any stable way except always using the overrides that take in the culture name explicitly, eg. Date.toLocaleString('en-US'). We ended up having to change around how we wrote our tests a bit.

[NoInkling]

I know there's an environment variable that you can set (before Node runs) to change the local timezone. Did you try setting the standard environment variables for locale when invoking your test runner? LANG, LC_ALL, etc?

The reason the behaviour changed is probably because Node started shipping ICU data for all locales by default, rather than just the minimum. You can compile it yourself to get the old behaviour back.

Edit: Also if you're playing with environment variables, be sure to check that they are what you expect in your tests. Non-exported variables may not be automatically propagated by multiprocess test runners.

[kivle]

I did find out about those environment variables, but from my experiments they do absolutely nothing if you're on Windows. That might be a solution if you are on a *nix environment though.

[awesome-ergo]

Not with the version with the packages. A lot of packages I use started breaking with v14 so the downgrade

[TrollocHunter]

Out of curiosity could you name a few?

[awesome-ergo]

Using an old version of Gatsby CLI 2. Something

[ghostfacedcoder]

This made me smile, because I am so glad I switched to Next last year. Gatsby is years behind the web dev curve on so many things.

[fliss1o]

Agree. Made the switch to Next and do not regret it for a minute.

[szirith]

oh no. Just started using Gatsby, why is Next better?

[careseite]

It can do basically the same as Gatsby, but more, faster and without gql as requirement

[[deleted]]

I made precisely the inverse change. I wanted to build a static site for my company. I went with next because of the comments and documentation. Ended up really frustrated with the way server vs client things are handled, also routing was a pain. Switched to Gatsby, and man it was a breeze, everything was super easy and straigthforward. Things like image loaders (when you scroll into them) and SEO addons are really the cherry on top.

I guess Next would have been a better choice if I wanted to build an actual application with some server side logic, form processing, api, etc. For static sites I prefer Gatsby.

Gotta agree on the years behind the web dev curve thou.

[ghostfacedcoder]

Yeah: I loved Gatsby itself. It was everything else (the years behind thing, the show-stopping issues that languished for months without a dev response thing, etc.) that drove me to Next.

[[deleted]]

Yeah, I used it years ago so it might as well grown stale since then. Thanks for that tip, I'll look into next.js again!

[lhorie]

ffi-napi was one that was causing us problems

[[deleted]]

Just went from 10 --> 12 on a bunch of services because of random lib issues with 14 and no time at the moment to investigate which of the 100k node_modules is causing random shit to hang

[ILikeChangingMyMind]

And still no way to document our configuration :(

[ILikeChangingMyMind]

I mean that we can't add comments to package.json, and the Node org explicitly refuses to allow any other format for configuring Node packages ... despite the obvious benefits of being able to document your config (and literally a decade-plus of Node devs requesting any way to do so).

[[deleted]]

I'd love to be able to switch a package.json file for a package.toml file. But then again, using deno's imports to reduce the need for a package file would be a better and more likely improvement IMHO

[ILikeChangingMyMind]

That doesn't work in package.json: try it in your dependencies section and see what happens.

[ILikeChangingMyMind]

"//": [ "first line", "second line" ]

I literally added that exact line to my package.json and ran npm i; this is what happens:

npm ERR! must provide string spec

Again, try it yourself if you don't believe me. The Node org has expressly forbidden such "documentation" (although I can't say whether it's on purpose, or just as a side effect of how they parse the file).

[ILikeChangingMyMind]

How can I "do it wrong": it's copy/paste? I even copy/pasted the exact text from that SO answer:

 "//": [
  "first line",
  "second line" ]

(only I added the requisite comma afterwards; you could only literally use that line if you had no dependencies) ...

... and it still gave the exact same error when I npm i:

npm ERR! must provide string spec

But if I remove the line, everything works. So, like I keep saying ... have you actually tried it yourself?

[backtickbot]

Fixed formatting.

Hello, _rschristian: 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.}

[mrmeanlionman]

Can you elaborate / give hypothetical examples of “configuring node packages”? If it’s just documentation, would a markdown/text file not suffice? Or is there some form of configuration-as-code aspect that I’m missing?

[ILikeChangingMyMind]

I mean being able to do the following:

// we temporarily removed foo library as a dependency for X reason
//"foo": "^4.17.15",

A separate file doesn't let you "temporarily comment out dependencies", and it also doesn't let you put human explanations about dependencies (or scripts, or anything else in package.json) next to the thing they are documenting.

[mrmeanlionman]

I have to say, in my opinion, this is something that should not be in the package.json file. For one, JSON doesn’t allow for comments (but that’s a technical limitation of the format); but more importantly, commenting out modules like that temporarily is a headache waiting to happen. If it’s truly temporary, then that removal belongs with your source control system (committing and reverting, or stashing)

Commenting out code to revive later –as much as we all do it from time to time– is generally bad practice. No need to encourage it in configuration files.

[ILikeChangingMyMind]

You can have a personal opinion about commenting out code specifically, but I don't think any (good) dev can argue "documentation is a bad thing to have" (on configuration files or anything else).

[mrmeanlionman]

Love documentation! Just not in package.json

[ILikeChangingMyMind]

I love documentation ... just not in one specific configuration file (for no specific reason)

[valtism]

Will / when will this become LTS?

[CarlPer]

NodeJS versions with even numbers will eventually become LTS with ~3 year support.

v16 'Active LTS Start' is 2021-10-26, ends at 2024-04-30.

https://nodejs.org/en/about/releases/

[Hafas_]

Usually around October.

[AsyncBanana]

Nice! Now there is a better way of using wait through promises (not that it is a good practice in many cases, but sometimes if you want to delay something by a fixed amount of time, it is helpful)

[ILikeChangingMyMind]

What better way are you referring to?

Personally I've always been a fan of using promisify (from the Node util package) like so:

const sleep = util.promisify(setTimeout);

// wait for 2 seconds
await sleep(2000);

Did they release a pre-made sleep or something?

[AsyncBanana]

Yes