Fix tests for node 26

[brianstrauch]

Closes #12047.

When running brew install node (defaults to v26) followed by npm test I get quite a few failures.

• Added a localstorage file to the test configuration to get around the lack of local storage in node 26.
• It looks like IndexedDB is used in place of localstorage in production, which was introduced by Integrate indexeddb for history and prefs sync with server #11141.
• Bonus: While debugging, I noticed that the in-memory storage fallback (let s = {}) is flawed since all of our tests expect null, not undefined if an item doesn't exist in storage.

[Copilot]

Pull request overview

This PR aims to address Vitest failures on newer Node versions (notably Node 26) by ensuring a usable localStorage backing store in the test runtime and aligning the in-memory Storage fallback behavior with expectations used throughout the codebase.

Changes:

• Configure Vitest’s Node process arguments to supply a temp --localstorage-file path for the jsdom test environment.
• Adjust the core/preferences in-memory storage fallback to return null (instead of undefined) for missing keys.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
vitest.config.ts	Adds Node exec args to provide a temp localStorage file for tests under newer Node versions.
modules/core/preferences.js	Tweaks the in-memory Storage fallback to better match localStorage semantics for missing keys.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

[k-yle]

thanks, lgtm. final question is whether the CI should run tests on node26 too

[tyrasd]

🤔

From what I can see, the crashes are actually coming from osm-auth which does not properly fall back to a polyfill when the localStorage object is undefined. See osmlab/osm-auth#152 for a proper fix for that.

Until then we could do the workaround of hacking¹ our polyfill into the globalThis object, or alternatively we could just disable the experimental webstorage support in vitest.config.ts:

    execArgv: [
        '--no-experimental-webstorage'
    ],

Which would be slightly nicer, as then we'd also not get the false positive warnings about missing --local-storage-file parameter in the logs.

What do you think?

Footnotes

1. which could be slightly dangerous as we only implement the subset of the API we need, but others might actually call, say localStorage.length potentially. ↩