Convert remaning runtime helpers to TypeScript

[nicolo-ribaudo]

Our source files are mostly written in TypeScript, with the exception of most of the runtime helpers that we inject in the compiled code. Since #16495 all those helpers are stored in individual files and pre-transpiled, so we can move all those that are still written in JS to TypeScript.

There are some rules/instructions to follows:

• Many imports currently use "bare specifiers", such as import toPropertyKey from "toPropertyKey";. They must be converted to relative imports always using the .ts extension, such as import toPropertyKey from "./toPropertyKey.ts";. The reason for using .ts even when importing .js files is that, when this issue will be completed, all those files will be using .ts anyway. If TS complain that it cannot find the types of the dependency because it's still written in JS, add // @ts-expect-error before the import.
• The files must type-heck when running make tscheck-helpers (or yarn tsc -p ./packages/babel-helpers/src/helpers/tsconfig.json, which is equivalent)
• Some of those helpers use absolutely unreadable variable names, such as https://github.com/babel/babel/blob/db3e9a6cbdaba16dc480a1f76a11b0d2ea84adc4/packages/babel-helpers/src/helpers/iterableToArrayLimit.js, because those files were "manually minified". No we minify helpers at build time, so we can afford to use readable variables: feel free to change them!

To coordinate this work, I split all our helpers in groups: those who want to help can leave a comment saying which group you want to work, and then start working on a PR :) If you want to work on multiple groups, start by claiming one and then after that the PR is merged you can claim a second one (and so on).

If it is the first time that you contribute to Babel, follow these steps: (you need to have make and yarn available on your machine)

1. Fork the repo
2. Run git clone https://github.com/<YOUR_USERNAME>/babel.git && cd babel
3. Run yarn && make bootstrap
4. Wait ⏳
5. Update the code!
6. Whenever you change a helper, you'll need to run yarn gulp generate-runtime-helpers to regenerate ./packages/babel-helpers/src/helpers-generated.ts (this is probably not needed if you just add types, but it is if you for example change variable names)
7. Once you are done, you can run make build to re-build everything, and then make test to run all the tests
8. Run git push and open a PR!

---

NOTE: Some of the helpers in this list are already written in TS, but they are failing type-checking. The task for those is to remove them from packages/babel-helpers/src/helpers/tsconfig.json's exclude list and fix the type errors.

• Legacy decorators
  • applyDecoratedDescriptors
  • initializerDefineProperty
  • initializerWarningHelper
• New decorators (@liuxingbaoyu)
  • defineAccessor
  • identity
  • setFunctionName (see note above)
  • applyDecs2311 (see note above)
• Arrays (@blakewilson)
  • arrayLikeToArray
  • arrayWithHoles
  • arrayWithoutHoles
  • iterableToArray
  • iterableToArrayLimit
  • iterableToArrayLoose
  • maybeArrayLike
  • unsupportedIterableToArray
  • slicedToArray
  • slicedToArrayLoose
  • toArray
  • toConsumableArray
• Objects (@SukkaW)
  • defaults
  • extends
  • objectDestructuringEmpty
  • objectSpread2
  • objectWithoutProperties
  • objectWithoutPropertiesLoose
• Reflection (@coelhucas)
  • defineEnumerableProperties
  • defineProperty
  • get
  • getPrototypeOf
  • set
  • setPrototypeOf
  • superPropBase
  • construct (see note above)
• Classes (@amjed-98)
  • assertThisInitialized
  • classCallCheck
  • createClass
  • possibleConstructorReturn
• Subclasses
  • createSuper
  • inherits
  • inheritsLoose
  • isNativeFunction
  • wrapNativeSuper
• For-of (@arslivinski)
  • creaeForOfIteratorHelper
  • creaeForOfIteratorHelperLoose
• Async functions/generators (@SukkaW)
  • asyncToGenerator
  • AsyncGenerator
  • asyncGeneratorDelegate
  • asyncIterator
  • awaitAsyncGenerator
  • OverloadYield
  • wrapAsyncGenerator
• Class fields (@Zzzen)
  • checkPrivateRedeclaration
  • classPrivateFieldInitSpec
  • classPrivateMethodInitSpec
  • classStaticPrivateMethodGet
  • classPrivateFieldLooseBase
  • classPrivateFieldLooseKey
  • readOnlyError
  • writeOnlyError
• Modules (@amjed-98)
  • interopRequireDefault
  • interopRequireWildcard
  • importDeferProxy
• Temporal dead zone (@amjed-98)
  • tdz
  • temporalRef
  • temporalUndefined
• Other
  • jsx
  • taggedTemplateLiteral
  • taggedTemplateLiteralLoose
  • instanceof
  • typeof
  • wrapRegExp
  • usingCtx (see note above)

[blakewilson]

I'm down to help out with Arrays!

[nicolo-ribaudo]

Thank you! If you need any help feel free to ask :)

[SukkaW]

I am going to work on Objects first!

---

Update

Finished in #16505.

[nicolo-ribaudo]

Thanks!

[coelhucas]

I can get Reflection 🙂

[Zzzen]

Class fields please!

[nicolo-ribaudo]

They are yours :)

@coelhucas After that #16505 is merged, you might need to rebase your changes to remove some @ts-expected-error comments introduced by that PR.

[arslivinski]

I would like to work on the For-of.

[nicolo-ribaudo]

It's yours :)

[SukkaW]

After taking a closer look, I want to also give Async functions/generators a shot.

---

Update

Async functions/generators is by far the most challenging one, and I am determined to be the one that conquers this down!

[magic-akari]

I am concerned about using TypeScript with Babel helpers. Does type really make sense?

In my experience, Babel helper is already js in downstream users' node_modules, and usually our tsc also turns on skipLibCheck.
The only place where it can make a difference is in the Babel repository itself for checking.

Do we have enough TypeScript code using Babel helpers so that the helper is imported and checked by tsc?
If the function is exported but not used, in such a case, Type has not fulfilled its purpose at all.

[nicolo-ribaudo]

@magic-akari Yes, helpers being written in TS is mostly for internal type checking in the monorepo (among the helpers themselves). All the helpers we added in the past few years are already written in TS because:

• it makes the DX when working on them much better, as autocompletion works better
• helpers can be imported by other helpers (even if many of them are not), exercising the cross-helper checks
• helpers are written in a very weird JavaScript, to maximize compatibility and minimize code size, and having types helps a lot with documenting what is going on

When published, helpers are never meant to be manually imported in code that people write, but they are just injected by Babel and thus at that point don't need type checking.

[amjed-98]

can I have Classes ?

@nicolo-ribaudo

Update:
finished in: #16511

[nicolo-ribaudo]

Yes!

[amjed-98]

can I get Temporal dead zone?

@nicolo-ribaudo

Update:
finished in: #16520

[nicolo-ribaudo]

Yes!

[amjed-98]

Modules?

[amjed-98]

quick question
can you give me a usage example for the _identity helper function in packages/babel-helpers/src/helpers/identity.ts?

does it accept a generic argument or is there a constraint?

/* @minVersion 7.17.0 */

export default function _identity<T>(x: T): T {
  return x;
}

@nicolo-ribaudo

[nicolo-ribaudo]

No constraint. I think currently we only pass functions to it, but let's keep it as generic as possible since we might use for other things.

[amjed-98]

legacy decorators?
@nicolo-ribaudo