We were unable to load Disqus. If you are a moderator please see our troubleshooting guide.

Benjamin Lupton • 7 years ago

How do you generate the declaration files so if you are publishing a package, others can consume your types?

Matt • 6 years ago

Good question! Here's the command you're after:

tsc --emitDeclarationOnly

Martin Freire • 6 years ago

I get this error
Option 'emitDeclarationOnly' cannot be specified with option 'noEmit'
Have you try it?

Matt • 6 years ago

Sorry, I had changed my tsconfig to be different from this post. This should work:

tsc --noEmit false --emitDeclarationOnly

Luís Fernandes • 6 years ago

But let's say we are using Webpack or other to bundle a package into a single file. What about the typings? What would be the best way to also only have 1 file for that? Because otherwise we will have the whole tree of typings. Is that viable?

Matt • 6 years ago

Hmm, good point. This hasn't affected me yet, as I only generate type definition files for libraries (to help those consuming the library). And I don't bundle libraries into a single file. I just compile the source tree into multiple files (using Babel). So the type definition files match perfectly, too.
Is this something that could work for you?

Luís Fernandes • 6 years ago

Hmmm, not sure. We usually use webpack to bundle the whole library into a single file (UMD) so it can also be used in the browser by including it in a script tag. Not worth it? I can see it backfiring if it is too big, as you wouldn't be using three shaking, etc.? Not sure...

Matt Welke • 6 years ago

You can do two different builds, one for the browser and one for NPM (CommonJS) consumers. The browser build can be one large JS bundle and the NPM build can be separate files with separate d.ts files matching in the tree.

This is actually good, because it means the NPM consumers don't have to import everything in your library just to use one thing from it. You can have them import from specific files and if they're bundling for the browser, their bundler will only include what they wanted.

An example is Lodash. You can write an import like: "import merge from 'lodash/merge';". Notice how they build it to allow this:

https://unpkg.com/lodash/ shows you the whole package build for NPM. Notice that it's many js files.

https://unpkg.com/lodash/me... shows you one of those files.

https://unpkg.com/@types/lo... shows you the whole package build's d.ts files. Again, all separate.

https://unpkg.com/@types/lo... shows you the one corresponding d.ts file.

swashata • 7 years ago

This is great and as a person starting with TypeScript, I couldn't be happier.

I am just stuck at what tslint preset to choose. I have been using eslint airbnb combined with prettier for last one and a half year. Any pointer on this? What is the industry recommended preset for tslint?

I use tslint-config-airbnb with some customisation :)

Matt • 6 years ago

Thanks! ESLint is becoming the linter of choice, even by the TypeScript team themselves. Check it out: https://eslint.org/blog/201...

MyUserInDisqus • 6 years ago

What's the purpose of using Babel as a transformer if you cannot write your code with custom transformers that would work in Typescript type checking too ?
I would love to see type checking working separately with other parsers like Babel. But currently using custom plugins (e.g. @babel/plugin-proposal-optional-chaining) will cause `tsc` command to fail.
I think Typescript should support and improve Babel with cross file information and other required features for the parser to support type checking.
Type checking should be separate from Parsing step. Typescript is limiting its potential with this constrained design.

姜希凡(Ivan Jiang) • 6 years ago

TypeScript supports optional chaining now at v3.7

Ziaullhaq Savanur • 6 years ago

Hey I have gone through the following link
http://artsy.github.io/blog...
By seeing at this I am little worried about using Babel with Typescript.
Can any body guide me here?
I am planing to use Jest for unit testing but in Jest getting started docs at the end it is written that

Note that there are some caveats to using Typescript with Babel, see http://artsy.github.io/blog.... Another caveat is that Jest will not typecheck your tests. If you want that, you can use ts-jest.

see at the end in the following link
https://jestjs.io/docs/en/g...

Matt • 6 years ago

Hey there,

I think if you follow this article, you'll find using TS + Babel pretty painless.

Most pain in the article you linked to comes from upgrading from Babel 6 to Babel 7, which does require a bit of work.

The caveats aren't too bad, and addressed in this article under "It’s not a perfect marriage".

Jest v24 now supports Babel and TS extensions out the box. No need to configure anything! Type checking can be done with a `check-types` command (as described in this article), no need to use `ts-jest`.

Here's an app creator to give you all the configs you need: https://github.com/iamturns...

Good luck!

Oren Mizrahi • 7 years ago

great job with the article. managed to sum up all quite easily!

Matt • 6 years ago

Thanks Oren!

Klaster_1 • 7 years ago

I'd add flaky metadata/decorators support to drawbacks, it's a very annoying letdown when used with Angular, DI basically doesn't work and you have to define static parameters like it's AngularJS all over again. eslint-plugin-typescript has some issues with auto fixing decorators too.

Wellington Domiciano • 3 years ago

Awesome post! Thank you very much :star_struck:

c01nd01r • 4 years ago
Saul Palazuelos • 5 years ago

found this very useful

Ben P.P. Tung • 5 years ago

yet another shit

Michael Jay • 5 years ago

I'm nearly crying. This article is EXACTLY what I needed. Thank you very very much.

Oliver Foster • 5 years ago

https://github.com/babel/ba...

@babel/proposal-class-properties This plugin adds properties after the constructor, which is a bit useless.

Mm • 5 years ago

is eslint-loader currently the only way to fail compilation on a linting error? What if I don't use webpack but want babel not to execute upon a linting warning/error?

Florian Hammer • 6 years ago

Your prediction was right. Typescript is in the top 10. But it was close. https://insights.stackoverf...

Mike Valeriano • 6 years ago

Checking this just now (august '19), since I'm being kinda "forced" to embrace TypeScript. I've had a bad time configuring tsconfig and tyring to lint at the same time....

But this guide helped me a to actually get it done correctly, and painlessly.

Thanks so much.

I just need to know how to reincorporate type checking into my linting, if such thing is possible. I want to see type errors alongside my linting warnings/erros and such. Will that be too heavy for the editor and make it slow?

Christopher Trevino • 6 years ago

Great article! This is the approach we’re going to use in react-dnd now. The problem for us is that the tsc targets were a bit too coarse and we wanted to think in terms of the browserlist option with preset-env.

Carl-Erik Kopseng • 6 years ago

Thanks for a good overview on how to get this set up. The end result addresses some of my main complaints when using Typescript in 2015, one of which was compilation speed.

What this doesn't cover is how to do a step-wise transition. For me, fixing 3978 typescript errors (actual count after doing the `find ...`) is a bit overwhelming and would stall development for two weeks. Just getting my 200 LOC helpers lib to compile nicely with the definitions from `react-redux` took well over an hour.

While doing git mv app.{j,t}s worked fine, doing it to any other file was a disaster. Existing Mocha tests quickly crashed on being unable to find the right files, even when registering Babel and adding suitable extensions:

mocha --extension js,jsx,ts,tsx --require @babel/register

Typically if doing git mv Logger.{j,t}s I'd get Error: Cannot find module './lib/logging/Logger'

Is there a way of doing the transition gradually for bigger (30-100 KLOC) projects?

Victor Cardins • 6 years ago

Excellent article! Could you provide some directions on how to integrate with webpack + react app? Thank you!

Caroline O • 6 years ago

https://github.com/Microsof...

This has some great examples! If you scroll down the 3rd example is React + Webpack

Victor Cardins • 6 years ago

Thank you much, Caroline! It helped!!!

Borek Bernard • 6 years ago

Awesome article! How would this work with project references? Right now, we use the good old `tsc` to build / transpile our code and have this in our app's tsconfig.json:

```
{
"references": [
{ "path": "../our-library" }
],
...
}
```

Then we run `tsc -b` in our app and let TypeScript transpile both the `app` and `our-library` (if it changed).

For Babel-enabled project, and say using Yarn workspaces to manage multiple packages inside a monorepo, how would this setup be replicated?

Thanks!

Mykel Chang • 6 years ago

Am I wrong or does it mean that you cannot prevent babel transpiling when a type error occured ?

Matt • 6 years ago

Hey Mykel, yes I think create-react-app works this way. I'm not sure it prevents transpiling, but shows the type checking errors during build. But personally I'm not a fan of that workflow (as described in the article), so haven't investigated much. Good luck!

Dan Spencer • 6 years ago

I've had a quick go at this but appear to be missing something. The TypeScript compiler can't check my types because it doesn't recognise the syntax of optional null chaining.

Matt • 6 years ago

You're right - TypeScript doesn't understand the syntax. Looks like we can use the `idx` library in the meantime. Sorry about that, have just updated the article (under 'Babel Macros') with more accurate info. Thanks!

Aleksandr Strutynskyy • 6 years ago

what a great article, addressed so many issues, i feel like trying TS now... and i hate strict typing with all my heart :)

but it will be useful skill at the interview, at some point.

Matt • 6 years ago

Thanks Aleksandr, it's a good time to give strict typing another chance!

Gerardo Lima • 6 years ago

using babel for typescript just doesn't make sense -- i.e: who does inject shimmers? but people hold on to the past ... too bad for them

Aleksandr Strutynskyy • 6 years ago

didn't you pay attention? it's for SPEED!!!

Mike Rogne • 6 years ago

Regarding drawback #4, "Legacy-style import / export syntax", here are some helpful links that I've bookmarked when trying to use TypeScript with Node.js:

https://stackoverflow.com/q...

https://github.com/Microsof...

Matt • 6 years ago

Thanks Mike! Any reason not to convert to ES module syntax?

Mike Rogne • 6 years ago

No idea. I have been moving to ES module syntax unless I'm using a library that explicitly won't let me -- which is super rare. I was mostly posting those links as a "If you arrived here via Google and are ripping your hair out, these links may help" comment 😉

John • 7 years ago

Great article! I've been thinking about adding babel to my transpilation stack (gulp->webpack->typescript) for a while, to be able to get goodies like optional chaining. One question though.. if I truly wanted to have the build fail on TS errors, is there any way I could have that, instead of the "check-types" script you propose above?

Matt • 6 years ago

Hey John, yes it's possible, and I think create-react-app works this way. But I'm personally not a fan of that workflow so haven't investigated much. Good luck!

Pietro Coelho • 7 years ago

Can you explain how to make this work with webpack?

swashata • 7 years ago

Actually, you don't do anything else, except for creating a rule for `ts,tsx` files with babel loader. Also add ts, tsx to resolve extension and you are good to go.

Pavel Nod • 6 years ago

Great article!!!

Read about TS and babel - want to know something new. And found an excellent explanation for babel macros 👍👌