Transition to vanilla javascript / ES Modules

[jimmywarting]

💻

• Would you like to work on this feature?

What problem are you trying to solve?

When writing the entire source code in TypeScript/Flow, types are checked throughout the entire code. That can be helpful at times, but more often than not it results in unneeded code complexity and build errors that slow down the development and maintenance of the Babels source code. I estimate that the introduction of TypeScript/Flow slows down code develepoment by some factor cuz of compile time and others factors. I don't believe it saves time, you will just spend it more upfront.

Beside, we now want ship stuff with ESM. TypeScript have had a long time to adapt to ESM ever since node 12.17 but haven't adapted it's extension-less philosophy that it should some how magically just rely on node's path resolver to fix the resolver.
ESM + typescript just simply don't work good together due this mess. Sure you can smash in a .js extension inside of a .ts file but this will just confuse the remote http-import thinking there is a js file somewhere when there isn't anyone.

TypeScript gets few things wrong and it don't always support the latest features, They will always stand in the shadow of JavaScript and will always be one or more steps behind. They are now buried in thousands of issues and seems to have a hard time to keep up? At some point TypeScript could become totally obsolete and unnecessary when/if optional typing becomes a thing that we can use.
I have been along for the ride in 12 years and see many "compile X to JavaScript" languages come and go.

• At some point CoffeeScript was the popular language to use but i never hear anyone using it anymore.
• Google proposed adding multiple VM support for Webkit to support Dart and even more language which didn't go down very well.

TypeScript will never become natively supported by the browser. So i always bet on JavaScript (or wasm).

Where do you think TypeScript will be in 5 years?

• Deno stop using TypeScript and switch to JavaScript and wished they did not support TypeScript
• Octokit/github is about to ditch TypeScript as well as there process to convert to ESM.
• I'm sure some of you have read the Pure ESM package (gist - by sindre) and most if not all of the complains comes from ppl who use typescript and has problems with esm.

Benefits of removing TypeScript and switch to JavaScript:

• Removes all build steps. The source code in the GitHub repositories could be 1:1 of what is used in production. The runtime code will be easier to read, debug, and contribute to.
• Source code will be the production code. Easier to debug and contribute to. no annoying SourceMap.
• JavaScript will always stay and be the default language.
• Can use newest features of JavaScript.
• No worries about typescript/esm and the extension-less problem.
• Can still have type safety support along with JSDoc.
• Less configuration
• less false errors and warnings (Sry TypeScript but it dose not fit in a loosed typed language)

Describe the solution you'd like

Rewrite the TypeScript source files into native JavaScript and add JSDoc, then generate d.ts files for typing

Describe alternatives you've considered

--

Documentation, Adoption, Migration Strategy

Add allowJs = true, switch switch everything slowly and steady to javascript with jsdoc
when publishing: generate d.ts files

[babel-bot]

Hey @jimmywarting! We really appreciate you taking the time to report an issue. The collaborators on this project attempt to help as many people as possible, but we're a limited number of volunteers, so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack community that typically always has someone willing to help. You can sign-up here for an invite.

[nicolo-ribaudo]

Just to clarify: are you asking to rewrite our source code to remove TypeScript/Flow, or are you asking to create a Babel plugin that transform TS code to JS+JSDoc?

[jimmywarting]

are you asking to rewrite our source code to remove TypeScript/Flow,

yes

or are you asking to create a Babel plugin that transform TS code to JS+JSDoc?

no

[merceyz]

Deno stop using TypeScript and switch to JavaScript

Important to note that they only did that for their internals, the "Deno standard library" is still TypeScript

and wished they did not support TypeScript

For their internals or in general? If its the latter, could you provide some sources for that?

[nicolo-ribaudo]

@jimmywarting We don't plan to move away from TS. In fact, we plan to expand TS usage in our codebase even more (to replace the files where we currently use Flow, since a Flow+TS codebase is definitely suboptimal).

That can be helpful at times, but more often than not it results in unneeded code complexity and build errors that slow down the development and maintenance of the Babels source code. I estimate that the introduction of TypeScript/Flow slows down code develepoment by some factor cuz of compile time and others factors. I don't believe it saves time, you will just spend it more upfront.

That's not true. We currently have some files using Flow, some using TS and some using JavaScript. Since we introduced TypeScript, our development experience has improved because thanks to the real-time type checks we need to check way less often what a function must be used. We have a huge internal API, so type checks help a lot.

Beside, we now want ship stuff with ESM. TypeScript have had a long time to adapt to ESM ever since node 12.17 but haven't adapted it's extension-less philosophy that it should some how magically just rely on node's path resolver to fix the resolver.
ESM + typescript just simply don't work good together due this mess.

Since TypeScript 4.5, their compatibility with the Node.js ESM behavior has improved by a significant factor. TypeScript 4.5 is still in pre-release, so you might have missed it!

Sure you can smash in a .js extension inside of a .ts file but this will just confuse the remote http-import thinking there is a js file somewhere when there isn't anyone.

import "foo" also confuses the HTTP import, since "foo" is not an URL 🤷 In general, the ESM resolution strategies used on Node.js servers are not meant to be used in an HTTP client. You can make them work using import maps, but then you can also make any extension work.

TypeScript gets few things wrong and it don't always support the latest features, They will always stand in the shadow of JavaScript and will always be one or more steps behind.

We currently support Node.js 6, and in the future we will support only Node.js 12+. Both support less language features than the last TypeScript version, so removing the build step will force us to use way older features than what we can currently use with TS. Also, TypeScript implements most JS features when they are still not part of JS but when they are only Stage 3, so TS is moving ahead of the language.

At some point TypeScript could become totally obsolete and unnecessary when/if optional typing becomes a thing that we can use.

I really like that proposal! And there are also a few similar proposals in the same problem space. However, migrating from TS to those proposals will be way easier than migrating from untyped JS to those proposals.

• I'm sure some of you have read the Pure ESM package (gist - by sindre) and most if not all of the complains comes from ppl who use typescript and has problems with esm.

Luckily we know how to avoid those integration problems! 😄

Benefits of removing TypeScript and switch to JavaScript:

• Removes all build steps. The source code in the GitHub repositories could be 1:1 of what is used in production. The runtime code will be easier to read, debug, and contribute to.

We don't use a build step just for TS. TS support is a detail in our build process. We also:

• Compile our code so that we can use the latest language syntax while still supporting old Node.js versions
• Automatically inject polyfills where needed
• Have a compile-time step that lets us remove some parts of code: by doing so we can develop Babel 8 and Babel 7 together, and choose which one we want to publish using a compile-time flag. We initially used different branches, but we found that a compile-time feature flag significantly improves our DX because we don't have to rebase the Babel 8 branch on top of the Babel 7 one, or to cherry-pick every commit.

You can see our full Babel config at https://github.com/babel/babel/blob/main/babel.config.js.

---

I have never seen an issue proposing to convert a project from TS to uncompiled JS. It looks like both in Octokit (octokit/octokit.js#2128) and in Deno it was a decision taken independently by the project maintainers. I'm curious: are you using Babel in a way that our TS usages affects you? Or is this more like a matter of principle against TypeScript or against build steps?

Btw, this is Babel: if it wasn't for build steps our project wouldn't exist. You are probably trying to convince the wrong people that they are worthless 😅

[nicolo-ribaudo]

You might also be interested on #11701. I'm currently working on it, but TS is not a blocker. The main blocker is Jest (and I'm solving it at #13966), and then we'll wait for the babel 8 release.

[jimmywarting]

are you using Babel in a way that our TS usages affects you? Or is this more like a matter of principle against TypeScript or against build steps?

It's just a mater of principle... and i like buildless setup too. But don't get me wrong i use typescript also in a sense. Types are grate and i'm in favor of it. I just don't like to have to compile all the time and i don't like the typescript syntax either + you can't just copy/paste and have it run in any other place,

i don't know if you have tried it but there is a // @ts-check that you could use in javascript files to apply the same typescript rules but with jsdoc. i also have a tsconfig.json with checkJs + allowJs; you get the benefits of both world, type safety, ide, and best of all no unnecessary compilation

Btw, this is Babel: if it wasn't for build steps our project wouldn't exist. You are probably trying to convince the wrong people that they are worthless 😅

I would like if this wasn't closed right of the bat so we could hear what other ppl think of this (better yet: move this into a discussion)

[nicolo-ribaudo]

The comment I wrote is the opinion of the team, so there isn't much to add 🤷
I would seriously consider this if it let us remove the build-step, but it can't for the reasons I posted.