Open samhh opened 2 years ago
the tsc plugin, a la typescript-plugin-toml, would handle the language server side of things
Reminds me of this for CSS Modules: https://github.com/timothykang/css-module-types
The Webpack plugin would handle runtime compilation and the tsc plugin, a la typescript-plugin-toml, would handle the language server side of things.
How would this work when we run tsc
to type check the project? If I understand correctly, TS language service plugins don't effect tsc
. Taken from https://github.com/RyanCavanaugh/sample-ts-plugin:
Examples of things language plugins cannot do:
- Customize the type system to change what is or isn't an error when running tsc
I think we'd still need to manually compile translation JSON to TS before we run tsc
.
Related TS issues:
You're right, if typechecking is limited to the editor then we'd be losing type safety versus compiling directly via intlc first and then running tsc.
Might it be worth considering ttypescript given how pervasive translation imports are?
The current Web workflow works pretty nicely with intlc able to compile everything in under a second, but it adds some extra moving parts separate from the main builds.
What we do right now is compile
*.translations.json
to*.ts
and import from the latter in TypeScript. What we could potentially do instead is import directly from*.translations.json
. The Webpack plugin would handle runtime compilation and the tsc plugin, a la typescript-plugin-toml, would handle the language server side of things. The pattern should ideally be configurable in both cases.The only question is whether the plugin infrastructure supports returning raw TypeScript code for tsc to check, which it'd obtain via a shell call to intlc. I haven't checked if the linked plugin is doing that or returning only computed type information. If the latter that might be doable but it'd be a good chunk more complex.