SceneryStack needs actual locale list for Locale type

[jonathanolson]

Otherwise manually specifying translation string keys for anything not in the "small example" list results in a type error.

[jonathanolson]

@zepumph we should discuss this at some point, and decide how to clean up docs, or whether this is a mistake. Type checking is passing.

[zepumph]

This makes me a bit worried. I remember that the "actual" solution was to use a calculated artifact directly from the babel list (ground truth), but we got rid of that because we didn't want to have the addition of a new babel locale without regeneration to break the type checker. Can you post a usage here? And note how you think this may influence maintenance if we just imported the babel json directly? Can't we import json in Typescript?

[jonathanolson]

Hmm, getting the typing DOES sound nice. SceneryStack is turning localeData into its own module. However our codebase I don't think supports importing json directly at the moment (we... used to do that with package.json, but I don't see it now?)

As a SECOND factor, for file-size we don't want to always import the FULL file (we'd need to keep it as a "import type" so it doesn't use a runtime dependency).

Thoughts?

[zepumph]

What about a generated d.ts from localeData file for localeType that lives in babel?

[jonathanolson]

That works (it wouldn't auto-update, but it would be right next to the file we are updating, presumably that would be easier?)

Although then we would have sims depending on TS code in babel, which is a bit unprecedented. Imagine... linting issues across versions. I'm actually not convinced that is better (has more potential issues in the future).

[zepumph]

Let's just have it be an output to updateLocaleInfo, live in that chipper directory, and have it run every night with daily grunt work.