[Karinon]

Mostly a typing cleanup. Behaviour should stay the same except for the fixes listed below. This is the first iteration of stricter types. The goal is to replace all occurrences of any in the end. This is not really a breaking change, but one could argue it is, as some of the types are now enforced.

Changes

• Dependencies: updated dev dependencies (cpx2, rimraf) and added @types/emscripten. The hand-written any types for the Emscripten module and FS are replaced with the official types.
• Error handling: new toError() helper in errors.ts, with tests. All catch (err: any) blocks now use unknown plus toError().
• Shared types: AnyTypedArray moved into types.ts and replaces the long typed-array unions it duplicated.
• Stricter constants and modes:
  • NC_CONSTANTS is now as const.
  • New FILE_MODES table, with derived FileMode / OpenMode / CreateMode types.
  • mode in Dataset() and the from* factories, including the public wrappers in index.ts, is now FileMode instead of string.
  • Worker messages are typed.
• Cleanup: removed duplicate NC_LONGLONG / NC_ULONGLONG entries from the getter maps. They are aliases of NC_INT64 / NC_UINT64 and only became visible as errors after as const.

Fixes found along the way

• Attribute and group-name lengths read as 64-bit values are now converted to number. Emscripten returns them as BigInt, which the old types hid.
• open() handles the worker path and the regular read path in one branch. Creating files works as before.

Notes

• TYPE_NAMES is commented out, since nothing used it.

[lazarusA]

pretty much in favour of deleting code (but some could remain as placeholders in the meantime, only if, needed and planned).

Is this good to go?

[lazarusA]

I think I wanna to use these somewhere else, but forgot, plus knowing what each meant was useful for debugging. So, maybe delete? if they are really not used.

[lazarusA]

where are these now?

[TheJeran]

Surprised it passed Linting without these.

[Karinon]

They are not (entirely) gone. They are part of the new dependency "@types/emscripten". Hence the

export interface EmscriptenModule extends globalThis.EmscriptenModule {

which is also the reason why the linting worked.

I thought it might make sense to reuse something already existing and just to extend it with the bits we need.

I am going to respond slower this week due to events in my company.

[TheJeran]

Was feeling dumb cause this didn't make sense. But the global EmscriptenModule is declared in node_modules,. So this is solid