Depends on what you mean by cross-module type-checking! TypeScript would still be running locally because Reflame doesn't run your typechecking for you yet (though we'll be working on it!), either on your laptop or in a CI server somewhere, so everything supported by your local TypeScript version should still work the same.
What Reflame does require is turning on the `isolatedModules` compiler flag in your TypeScript config, so it can help you avoid features that would block isolated module compilation (that would similarly block things like Babel/SWC that only transpile individual modules as well).
What I’m asking is, even if you support type checking how can it fit usefully into your compilation model, given you can’t do any cross-module analysis?
Or more pithily: a fast linker isn’t impressive if it has no error handling.
So JS has this really nice property where things really can be just deployed as independent modules, and they will just work together without any cross-module compilation or analysis needed. It's a big part of what makes Reflame's approach possible.
That said, Reflame does actually perform dependency analysis on the entire module graph, persists it, and then updates it in response to every change. We're mostly doing this for optimizations like preloading only modules reachable from the entry point to flatten the network waterfall, but we also use it to provide nice error messaging as well. Here's a quick PR showing the dependency analysis in action: https://github.com/reflame/example-typescript/pull/2
We do this by doing analysis on each module as they come in to generate metadata on what modules they depend on, so subsequent modules can build up the dependency graph using just that metadata for each module, without having to have download the full code or analyze them again.
So JS has this really nice property where things really can be just deployed as independent modules, and they will just work together without any cross-module compilation or analysis needed.
If you're tolerant of undefined behavior when interfaces don't match expectations, every language has this property. In truth it's not really nice!
Comments
This means it's impossible to do any cross-module type checking, correct?
Depends on what you mean by cross-module type-checking! TypeScript would still be running locally because Reflame doesn't run your typechecking for you yet (though we'll be working on it!), either on your laptop or in a CI server somewhere, so everything supported by your local TypeScript version should still work the same.
What Reflame does require is turning on the `isolatedModules` compiler flag in your TypeScript config, so it can help you avoid features that would block isolated module compilation (that would similarly block things like Babel/SWC that only transpile individual modules as well).
Luckily those features are rarely used to begin with, here's the relevant bit in the example TypeScript repo with more about this: https://github.com/reflame/example-typescript/blob/main/tsco...
What I’m asking is, even if you support type checking how can it fit usefully into your compilation model, given you can’t do any cross-module analysis?
Or more pithily: a fast linker isn’t impressive if it has no error handling.
So JS has this really nice property where things really can be just deployed as independent modules, and they will just work together without any cross-module compilation or analysis needed. It's a big part of what makes Reflame's approach possible.
That said, Reflame does actually perform dependency analysis on the entire module graph, persists it, and then updates it in response to every change. We're mostly doing this for optimizations like preloading only modules reachable from the entry point to flatten the network waterfall, but we also use it to provide nice error messaging as well. Here's a quick PR showing the dependency analysis in action: https://github.com/reflame/example-typescript/pull/2
We do this by doing analysis on each module as they come in to generate metadata on what modules they depend on, so subsequent modules can build up the dependency graph using just that metadata for each module, without having to have download the full code or analyze them again.
If you're tolerant of undefined behavior when interfaces don't match expectations, every language has this property. In truth it's not really nice!