We were unable to load Disqus. If you are a moderator please see our troubleshooting guide.
Good question! Here's the command you're after:
tsc --emitDeclarationOnly
I get this error
Option 'emitDeclarationOnly' cannot be specified with option 'noEmit'
Have you try it?
Sorry, I had changed my tsconfig to be different from this post. This should work:
tsc --noEmit false --emitDeclarationOnly
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?
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?
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...
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.
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 :)
Thanks! ESLint is becoming the linter of choice, even by the TypeScript team themselves. Check it out: https://eslint.org/blog/201...
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.
TypeScript supports optional chaining now at v3.7
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...
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!
great job with the article. managed to sum up all quite easily!
Thanks Oren!
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.
Awesome post! Thank you very much :star_struck:
3) Const enums.
No longer relevant
https://babeljs.io/docs/en/...
https://github.com/babel/ba...
found this very useful
yet another shit
I'm nearly crying. This article is EXACTLY what I needed. Thank you very very much.
https://github.com/babel/ba...
@babel/proposal-class-properties This plugin adds properties after the constructor, which is a bit useless.
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?
Your prediction was right. Typescript is in the top 10. But it was close. https://insights.stackoverf...
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?
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.
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?
Excellent article! Could you provide some directions on how to integrate with webpack + react app? Thank you!
https://github.com/Microsof...
This has some great examples! If you scroll down the 3rd example is React + Webpack
Thank you much, Caroline! It helped!!!
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!
Am I wrong or does it mean that you cannot prevent babel transpiling when a type error occured ?
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!
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.
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!
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.
Thanks Aleksandr, it's a good time to give strict typing another chance!
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
didn't you pay attention? it's for SPEED!!!
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:
Thanks Mike! Any reason not to convert to ES module syntax?
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 😉
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?
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!
Can you explain how to make this work with webpack?
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.
Great article!!!
Read about TS and babel - want to know something new. And found an excellent explanation for babel macros 👍👌
How do you generate the declaration files so if you are publishing a package, others can consume your types?