4 ms·

But you're basically trying to superset the TS compiler. If this doesn't cover TS typechecking then it fails on it's promise of a single pass compiler stack. A

But you're basically trying to superset the TS compiler. If this doesn't cover TS typechecking then it fails on it's promise of a single pass compiler stack. Are you suggesting that TS team is so incompetent or legacy burdened that their codebase is impossible to extend. What use case of TS would you exclude to arrive at simpler code base ? Writing a transpiler that ignores type checks is probably simple but also quite useless for dev workflow - if I need to run a separate type checker might as well run a separate linter and compiler, the tech is established.

brundolf 6y ago
The TypeScript plugin for Babel already works this way: it strips out the type annotations to make the code understandable to plain JS interpreters, nothing more. Most people do their type checking through their editor or some other tooling. The coupling of building and checking in a single step, in the case of a dynamic language, is really just a matter of convenience for the implementers (as well as historical tradition). Unlike C, in TypeScript type information is not actually needed to output runnable code.
- rubber_duck 6y ago
  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.
rmthw 6y ago
> Are you suggesting that TS team is so incompetent or legacy burdened that their codebase is impossible to extend. I'm not suggesting at all that they're incompetent, but you seem to be... Typescript's goal was not extensibility in the way it would be needed for Rome to use it as its base. There is nothing wrong with that. Also, it's not "incompetence" to write a codebase that is hard to extend or modify to do something in a completely different way. It's just a difference of priorities. Of course it would be better to only have easily-modifiable codebases in the world, but this is not possible. Teams might have other conflicting goals. Don't fool yourself into thinking that a good codebase has every single positive attribute in the world just because it's a good codebase, or because its authors are good coders. Webpack was harder to modify than creating Rollup from scratch, GCC was harder to modify than it was to create LLVM from scratch, Linux is immeasurably harder to modify than Minix if you want it to do things it was not . But it doesn't mean that those codebases are worse or better. -- > What use case of TS would you exclude to arrive at simpler code base ? Why would I want to exclude any use case from Typescript? I actually mentioned Rome's raison d'être is to have more things than other transpilers. It's a matter of architecture and early choices, of how the parser/ast/pretty-printer were implemented. Not really a matter of features we can remove.
rmthw 6y ago
Also, the ball has been in Typescript's court for a while to provide a fast, easy to use typecheck-only API that receives an AST and can be used by other tools that already have parsers. If that existed, it would allow Typescript it to be embeddable, and Rome could use that. People have been asking for it for half a decade.

brundolf 6y ago

The TypeScript plugin for Babel already works this way: it strips out the type annotations to make the code understandable to plain JS interpreters, nothing more. Most people do their type checking through their editor or some other tooling. The coupling of building and checking in a single step, in the case of a dynamic language, is really just a matter of convenience for the implementers (as well as historical tradition). Unlike C, in TypeScript type information is not actually needed to output runnable code.

rubber_duck 6y ago
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.

rmthw 6y ago

> Are you suggesting that TS team is so incompetent or legacy burdened that their codebase is impossible to extend. I'm not suggesting at all that they're incompetent, but you seem to be... Typescript's goal was not extensibility in the way it would be needed for Rome to use it as its base. There is nothing wrong with that. Also, it's not "incompetence" to write a codebase that is hard to extend or modify to do something in a completely different way. It's just a difference of priorities. Of course it would be better to only have easily-modifiable codebases in the world, but this is not possible. Teams might have other conflicting goals. Don't fool yourself into thinking that a good codebase has every single positive attribute in the world just because it's a good codebase, or because its authors are good coders. Webpack was harder to modify than creating Rollup from scratch, GCC was harder to modify than it was to create LLVM from scratch, Linux is immeasurably harder to modify than Minix if you want it to do things it was not . But it doesn't mean that those codebases are worse or better. -- > What use case of TS would you exclude to arrive at simpler code base ? Why would I want to exclude any use case from Typescript? I actually mentioned Rome's raison d'être is to have more things than other transpilers. It's a matter of architecture and early choices, of how the parser/ast/pretty-printer were implemented. Not really a matter of features we can remove.

rmthw 6y ago

Also, the ball has been in Typescript's court for a while to provide a fast, easy to use typecheck-only API that receives an AST and can be used by other tools that already have parsers. If that existed, it would allow Typescript it to be embeddable, and Rome could use that. People have been asking for it for half a decade.