3 ms·

I know how it works and I work with TS on a daily basis - the problem is you can't rely on editor type checking because all editors (Idea and TS language server

I know how it works and I work with TS on a daily basis - the problem is you can't rely on editor type checking because all editors (Idea and TS language server) do type checking on the currently open file - so as soon as your module is referenced from somewhere else you won't get editor notifications if your changes broke that module unless you open that file - using this alone is useless on large projects. I would argue editors already do a better job at linting and lint rules are mostly file local anyway so the "single pass lint on each build" is not that useful. Having type checking as a part of the compile process is the best way to leverage typescript (you can fork the checking process so it doesn't block output for faster reload experience)

brundolf 6y ago
It's entirely possible then to use tsc as a "global" typechecker for the purposes of your dev workflow, without making it a part of your build process (unless you're doing CI, in which case it could still be a separate, preliminary pass that doesn't have to be bound up in the actual build stage). All I'm saying is, especially for a project like Rome that has so many other irons in the fire, I think it's a fully legitimate decision to focus on builds alone and parse-but-not-typecheck TypeScript code, leaving the latter to projects like tsc that have much bigger teams and already do a great job of it.
- rubber_duck 6y ago
  But what's the value proposition of this solution then ? If I need to run separate processes anyway what's the benefit over running webpack with TS and a fork checker ?
  - rmthw 6y ago
    Better error messages, an error-recoverable parser, faster speed, consolidation into a single tool, additional ability to lint/pretty-print/minify/test instead of just transpiling and bundling, having zero dependencies, having a smaller codebase. Maybe those things are not important for you, but they are for the Rome author and for many people in the community. Also with brundolf's solution you can run the TSC typechecker (but not the transpiler/emitter) and Rome in parallel, making good use of modern multi-core processors. With Webpack+TSC you'll have to typecheck, transpile and bundle all in series. This might be very significant.
  - brundolf 6y ago
    There are lots of use-cases for producing a working build that doesn't necessarily pass type-checks. Active development, for one. I often find myself hacking on something and actively ignoring certain TypeScript errors that I know won't cause breakage, until I'm at a point where I want to start polishing things up. During this time I may need to test out the functioning-if-unsafe iterations, and I don't want to be blocked by errors that I plan to clean up later. Another case is if you're building a clean checkout; if you already know there are no type errors, there's no need to check again. The two are simply separate, if related, concerns.

brundolf 6y ago

It's entirely possible then to use tsc as a "global" typechecker for the purposes of your dev workflow, without making it a part of your build process (unless you're doing CI, in which case it could still be a separate, preliminary pass that doesn't have to be bound up in the actual build stage). All I'm saying is, especially for a project like Rome that has so many other irons in the fire, I think it's a fully legitimate decision to focus on builds alone and parse-but-not-typecheck TypeScript code, leaving the latter to projects like tsc that have much bigger teams and already do a great job of it.

rubber_duck 6y ago
But what's the value proposition of this solution then ? If I need to run separate processes anyway what's the benefit over running webpack with TS and a fork checker ?
- rmthw 6y ago
  Better error messages, an error-recoverable parser, faster speed, consolidation into a single tool, additional ability to lint/pretty-print/minify/test instead of just transpiling and bundling, having zero dependencies, having a smaller codebase. Maybe those things are not important for you, but they are for the Rome author and for many people in the community. Also with brundolf's solution you can run the TSC typechecker (but not the transpiler/emitter) and Rome in parallel, making good use of modern multi-core processors. With Webpack+TSC you'll have to typecheck, transpile and bundle all in series. This might be very significant.
- brundolf 6y ago
  There are lots of use-cases for producing a working build that doesn't necessarily pass type-checks. Active development, for one. I often find myself hacking on something and actively ignoring certain TypeScript errors that I know won't cause breakage, until I'm at a point where I want to start polishing things up. During this time I may need to test out the functioning-if-unsafe iterations, and I don't want to be blocked by errors that I plan to clean up later. Another case is if you're building a clean checkout; if you already know there are no type errors, there's no need to check again. The two are simply separate, if related, concerns.