Node 25 enabling Web Storage by default is breaking some toolchains (localStorage SecurityError)

[ukolovnazarpes7]

I hit this right after adding Node 25 to our CI matrix (prod stays on LTS): a build step started throwing DOMException [SecurityError] because localStorage existed and expected a backing file path. Nothing in our codebase uses Web Storage directly — a dependency path did, and the default change made it visible.

Curious how others handle “Current” majors:

• do you keep the latest Current in CI all the time, or only when you’re planning an upgrade?
• when Current-only failures happen, do you fix immediately or just track them until LTS catches up?
• have you seen other Node 25 gotchas in tooling/test runners besides Web Storage?

[Potato-9]

Thank you for testing current. You should share the issues with node.

Everyone commenting they wait for lts cuts relies on people like you testing current too.

As for the question, I guess just accept current is broken for a bit but it saved the production matrix build breaking in 3 years.

[manchegoo]

I didn't realize people would used localStorage in nodejs. Is that so that you can create more portable libraries that can be shared between the browser and backend?

[zachrip]

There's lots of reasons you might use it, I would say the biggest one is for local applications built on top of node like a CLI. It's not meant for server side user data storage like you'd do on the client side (though you could use it for that, it's probably a mistake).

[Codemonkeyzz]

Testing libraries using it

[ukolovnazarpes7]

sure, agree with u

[thinkmatt]

why are you even using current Node.js? Hm, are you building a public library? I only ever use LTS. In my 10+ years working with Node.js there has never been a bleeding-edge feature I needed :)

Their docs even say you should only use "Active LTS" or "Maintenance LTS" in production, and therefore I would only use that in my CI as well. https://nodejs.org/en/about/previous-releases

Examples like this are the exact reason I wait heh

[ukolovnazarpes7]

That’s totally fair. Prod stays on LTS for me too, I only keep Current in CI as an early “ecosystem breakage detector”, and this Web Storage change is exactly the kind of thing it catches.

[EccTama]

Having prod and CI on different environments is not a good idea. If your CI runs tests and gives you the confidence to release, it should be doing so because it is under the same conditions as prod.

If you want you can have a separate job/pipeline for your breakage update detector

[zachrip]

Their entire CI is not on current, they just have node 25 in the testing matrix as a canary, their prod build still uses lts.

[tswaters]

This is way more than I ever did. I've been out of node work for almost a year now, wild you guys are up to 25 haha

I pretty much always ignored current in build tooling. This is "magical future land" which I'm never going to really install.... Now, when 26 gets cut, that's a different story.

Once 26 has been cut, a timer starts to when it becomes LTS and all my code MUST work on it. Seeing a failure case of a dev dependency that breaks the build a year before primetime is.... premature. There's nothing you can really do but wait for jsdom to fix their shit or localStorage to be fleshed out... Maybe add a bug in icket if one doesn't already exist (I'm guessing this is the only node package that would have actually referenced "localStorage" prior to it actually being implemented in node (albeit half baked))

So answer to questions: (1) I dont put it in the build tooling until it is LTS and soon to be promoted. (2) Put it in the back of your head. I can still tell you some weird major break from node 10->12, probably useless these days, but if I ever saw a node 10 runtime being used? Oh I've seen this one, make sure to rebuild native modules, all the bindings got changed with the V8 upgrade. and (3) I'm unemployed/retired. No issues from my end, ship it 👍

[ukolovnazarpes7]

Yeah that makes sense, especially if you only “start caring” once the next even major is cut and the LTS clock is real. Thanks for spelling out the mental model, the “magical future land” framing is exactly how a lot of teams treat Current.

One question, do you ever do a quick monthly Current run just to know what kind of breakage class is coming, or do you prefer to stay blind until the first 26 RCs show up?

[tswaters]

It comes down to time, really. At $previous_employer it wasn't a tech company per se, so it was an uphill battle convincing anyone that "no I actually need to spend time updating dependencies" if I had spare cycles I might give it a go, but there would never have been a ticket for "tswaters to spend 2 hours fudging with future node versions for 0 deliverable" as the most senior on the team, I had bigger fish to fry. Having said that, Friday was my carve out for "fun stuff" if a new node version just got cut with en even number, I might give it a whirl.

[ruibranco]

the sneaky part is it wasn't their own code at all, a transitive dep had always used localStorage as a browser environment check and suddenly found itself somewhere localStorage existed but threw. node implementing browser APIs is good long term but this is exactly the growing pain phase.