5 ms·

I'm using this to compile typescript lambda functions for AWS with great success. Combined with cdk and its NodeJsFunction you can even deploy/compile without l

• tiew9Vii 5y ago
  I looked at using ESbuild and I use Typescript. It was all looking good until reading the docs and it said ESbuild doesn't typecheck Typescript and to rely on your IDE to flag errors. Is that correct and how is that working for you practically if it is? The whole point for Typescript for me is to have a compiler typecheck my code and block errors at compile time. ESbuild not typechecking seemed like a major contradiction to using Typescript so I set up a Webpack build using the standard ts compiler. I've been out the loop of client side stuff a couple of years so to start was bit of a rabbit hole. Grunt/Gulp had gone and now Webpack seems common with a growing fanbase for ESbuild because of it's speed.
  • kitd 5y ago
    Practically, it isn't an issue if you use VSCode which has the Typescript language server built in to catch type errors for you. If you want, your build script can include `tsc -noEmit` to type check before the build.
    • EugeneOZ 5y ago
      Only if a project is pretty small. Change in one place, especially if it's a reusable code, might ruin code in multiple different places and IDE will not recompile the whole project on every change, it will only watch your currently opened files and, maybe, some files in opened folders.
      • simlevesque 5y ago
        Did you reply to the wrong comment ? The --noEmit does not have the issue you talk about.
        • EugeneOZ 5y ago
          yes, sorry
  • nsonha 5y ago
    By "supporting typescript" it parses typescript code and won't fail. That is what a bundler promises. Bundler doesn't have to do the typechecking. It is actually conventional to set it up that way for any bundler. In my job we have webpack bundling typescript with babel in the "build" step. We could've use ts-loader but we want hot reload to be fast. Then in the "check" step we have ts, linter, unit tests. Those run on CI.
  • acid__ 5y ago
    Not blocking on typecheck failures is one of my favorite features of TypeScript -- you can rapidly test/debug/iterate on code with "broken" or incomplete types while in the prototyping stages of feature development.
  • lstamour 5y ago
    This is pretty common if you're looking for build performance. E.g. typecheck as a lint step with tsc, build with babel removing your typescript (it doesn't typecheck either), etc. It's true that tsc on its own can replace a build step for some folks, but you'll quickly find it limiting both in the options to rollup or combine files and in its ability to be extended with plugins (unlike Babel), etc. On the other hand, tsc and its language server is a first-class type-checker when run with no-emit. ;-) I haven't played as much with esbuild yet but it's on my todo list.
  • Vinnl 5y ago
    Consider TypeScript like a linter. ESBuild doesn't run ESLint for you either - you can run it separately, or in parallel. This means that for example, during development, you can see your running code quickly, while your editor runs tsc to highlight type checking errors. And in your build system, you can produce a production bundle to test while in parallel checking for type errors.
    • EugeneOZ 5y ago
      It's not a linter, far from it.
      • Sammi 5y ago
        I downvoted you because that's not what was said.
        • EugeneOZ 5y ago
          Appreciate the explanation. But: > Consider TypeScript like a linter
          • samhw 5y ago
            There's a difference between is a linter and is like a linter [in this context].
    • chrisjc 5y ago
      First, forgive my ignorance of the JS/TS and bundler ecosystems. > while in parallel checking for type errors. Why are you suggesting this not be done during development? Is it bc while ESBuild is fast and runs in parallel, it's still only as fast as the slowest parallelized task, and in this case the slowest task is checking for type errors? And I assume checking for type errors is the slowest because it has to invoke an external resource, tsc? Would it not make sense to have two development bundlers then? One for getting your code up and running quickly, and a second that outputs a dummy build artifact, but allows a more thorough production-like build that includes type checking (or other long running activities)? That way you get all the verification you would like, but don't pay a price on waiting for your code to deploy?
  • RobertKerans 5y ago
    You're likely literally doing the same thing with Webpack. There is only one complete implementation of the TS compiler in existence, so you have to use that to typecheck, it doesn't matter what bundler tool is used. If you need the type definitions as part of the output (eg you are distributing a library), then you have to involve the compiler to construct the output definition files, but for the code itself, it doesn't really matter because you're just generating JS. The TS compiler is very slow (and in any case is not designed to produce code bundles - it just dumbly translates all the TS to JS), so the standard way to speed this up is to use a module bundling tool that ignores the types and compiles the code as JS, and have the TS compiler set to not emit any files itself. Nothing in the above precludes using the compiler to typecheck the code, that's the primary usecase & what sibling is saying about thinking of it as a linter: if typechecking fails, don't build
  • dkdbejwi383 5y ago
    `eslint && tsc --noEmit && esbuild` or something like that, just simple process chaining. Means you can build something you know is going to be illegal to the TypeScript compiler, but you want to very quickly test an assumption, for example.