spheredev
Investigate implementing stricter module resolution semantics
Node.js 13.2.0 was released recently with support for ECMAScript modules enabled by default. Notable about this is that any ESM import referring to a file must include the full filename, including the extension, like it is in the browser. This means there are now three platforms whose ESM imports work this way:
- Web browser
- Node.js
- Deno
While there is no formal standard for module resolution (the ECMAScript specification leaves this entirely up to the host), this sets enough precedent to consider full-filename imports to be the de facto standard--and miniSphere is therefore an outlier in supporting extensionless imports. It's at least worth looking into whether miniSphere can be made to align without undue breakage.
This would be a major breaking change, and since module resolution semantics are technically part of the Sphere v2 API--the first two levels of which are frozen--some serious thought needs to go into how to do it without breaking existing code. The idea right now is to only require a full filename when Sphere.Game.apiLevel is 3 or higher. While higher-level functions are always available regardless of what the manifest says, breaking changes can't be introduced this way for obvious reasons.
Also worth noting: miniSphere supports require() in ESM code, albeit only with an absolute path. Node.js only supports it in CommonJS code. So yeah... open question whether to remove require-in-ESM support now that .cjs is a thing.
Also worth noting is that if a game wants to support Oozaru it already needs to use full-filename imports, as this is the only way the browser will be able to load them. It would be nice to have this enforced even when using the desktop engine.
This is more or less implemented now. If the game manifest specifies an apiLevel of 4 (or, eventually, higher), module resolution behavior aligns with Oozaru.