Final configuration changes in preparation for TS

[nicolo-ribaudo]

Q	A
Fixed Issues?	Closes #12342
Tests Added + Pass?	Yes
Documentation PR Link
Any Dependency Changes?
License	MIT

This PR is a trimmed down version of #12342, keeping the following changes:

• .d.ts files are stored in lib instead of dts, so that TS can resolved them without using "types" in package.json
• Yarn workaround to avoid downloading @types/babel__* packages that cause conflicts

The differences are:

• Let's only focus the migration on src folders for now
• .d.ts exclusion from published packages is centralized in Makefile, so that it's easy to undo when we decide to publish them and we don't have to update every .npmignore.
• Use @babel/parser instead of typescript for prettier
• While talking with @zxbodya he mentioned that the problem with autogenerated tsconfig.json files is that many of them are customized, but I manually checked them and tsconfig.json files need to be manually written in Migrate Babel from Flow to TypeScript (except Babel parser) #11578 are:
  • @babel/standalone, because it needs DOM typings
  • @babel/parser, which doesn't have anything special per se but the parser is so badly typed in Flow that tsconfig.json is pointing to the manually-written .d.ts definition we already have.

The tsconfig.json generation script has easily been updated to allow manually written tsconfig.json files (it will not overwrite them), so this problem is solved.
Also, the TS team is looking into automatically inferring references from package.json (ref: microsoft/TypeScript#25376) and they even create a poc tool similar to our script to automatically generate tsconfig.json files in the meantime 🙂 (ref: https://github.com/weswigham/tsautoref)

My goal is to keep the migration as much centralized as possible: the more we can centralize configs (tsconfig.json, non-published .d.ts), the easier it will be to make changes when we'll start publishing type definitions.

If there will be any package-specific problem, or any possible future concern that doesn't impact the current phase of the migration, let's defer the discussion about it when/if it will actually happen. Same applies for tests: let's keep them JS-based for now (we might want to enable TypeScript allowJS option in the future maybe).

I tried applying this PR on top of #11578 in this branch and you can see on Travis that it works. Testing it locally, my editor (vscode) correctly typechecks these files and "go do definition" works! (thanks to #12342 (comment)).

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/32501/

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 36c7044:

Sandbox	Source
babel-repl-custom-plugin	Configuration
babel-plugin-multi-config	Configuration

[zxbodya]

• .d.ts exclusion from published packages is centralized in Makefile, so that it's easy to undo when we decide to publish them and we don't have to update every .npmignore.

nice! I like this

[zxbodya]

will this also remove @babel/types/lib/index.d.ts? (it is currently published)

[nicolo-ribaudo]

It's regenerated in the line right after 🙂
It was easier to delete and re-generate it, rather than writing a Makefile loop to delete only everything else.

You can see the @babel/types and @babel/template (which already uses ts) published using this PR: https://drive.google.com/file/d/1TSyN9huOsGBIekpRv9Yf50DQEPuL4dED/view?usp=sharing (extracted from our e2e tests on CircleCI)

[zxbodya]

It's regenerated in the line right after 🙂

nice, missed that

[merceyz]

Also, the TS team is looking into automatically inferring references from package.json (ref: microsoft/TypeScript#25376) and they even create a poc tool similar to our script to automatically generate tsconfig.json files in the meantime slightly_smiling_face (ref: https://github.com/weswigham/tsautoref)

This has been requested as a feature for the TypeScript plugin in Yarn as well, should be doable rather easily in the afterAllInstalled hook

[nicolo-ribaudo]

This has been requested as a feature for the TypeScript plugin in Yarn as well, should be doable rather easily in the afterAllInstalled hook

I don't think this should go in Yarn's official plugins (the only team that can do something official about it should be TypeScript's), but I'll happily extract this script as a yarn plugin if you think that it will be needed by others!

EDIT: Looking at the plugin, I think this feature fits in it. I can prepare a PR next week if you are interested.

[merceyz]

EDIT: Looking at the plugin, I think this feature fits in it. I can prepare a PR next week if you are interested.

Exactly, that would be nice :)

[nicolo-ribaudo]

I'm glad that we are ready to start!