Migrate JSBI source to TypeScript.

[12wrigja]

This is based off similar work I did for js-temporal/temporal-polyfill#21.

Open questions:

• how does changing "type" in package.json potentially affect JSBI users?
• does the JSBI source need to be moved into a folder in order for the sourcemaps to end up correct in the npm package?
• does the TS source need to be included in the package as well (via the package.json files list?)
• is es2015 "low-enough" of a tsc emit before passing to babel? Or should the tsc emit be a much higher level emit and let babel do the bulk of the transpilation?

[jakobkummerow]

Source changes look good, with a few minor comments.

What's with the (internal) functions that haven't received type annotations?

Hopefully Mathias can say more about the open questions.

Regarding target ES level: keep in mind that JSBI is squarely targeted at old browsers. We've had people specifically request IE11 compatibility fixes before. I'm not sure how they dealt with the fact that class JSBI is an ES2015 feature. So it might even make sense to target ES5. (For the majority of the code, it shouldn't make a difference anyway.)

[12wrigja]

The problem with es5 transpilation is that the tsc output for class extends Array is broken when transpiling to es5. See this TypeScript playground example as a minimal repro.

[12wrigja]

"What's with the (internal) functions that haven't received type annotations?" I had another branch with these and forgot to merge it in before pushing/reviewing. PTAL. I tried to infer the right types for things based on how they were used, but there's at least a couple places where the tsc control flow can't infer the right things, so some casts were necessary to retain the existing code.

[12wrigja]

@justingrant You did a great job finding and helping me figure out the source-mapping issues with the Temporal TS migration - would you mind taking a look at JSBI as well?

[jakobkummerow]

Code changes LGTM. I'll leave the packaging questions to other reviewers.

[mathiasbynens]

how does changing "type" in package.json potentially affect JSBI users?

See inline comment. Can we avoid making this change?

does the JSBI source need to be moved into a folder in order for the sourcemaps to end up correct in the npm package?

Hmm, I’m not sure… Could you test with DevTools?

does the TS source need to be included in the package as well (via the package.json files list?)

No. The way I think about this is: the fact we’re using TS is an implementation detail, and does not influence the library that we end up publishing. We could include .d.ts typings in the package, however, since this is useful for developers.

is es2015 "low-enough" of a tsc emit before passing to babel? Or should the tsc emit be a much higher level emit and let babel do the bulk of the transpilation?

The current approach seems fine to me.

[mathiasbynens]

It's annoying that TypeScript doesn't support this (I guess?), because it breaks d8 benchmarks/sub.mjs — we now have to always test the compiled output instead.

[mathiasbynens]

Released as v3.2.0.