react-native: Template `tsconfig.json` does not support BigInts

Appreciate for understanding folks.

I’ve just tested it: the issue can be reproduced by writing BigInt(2) ** 256n and running npx tsc in the project directory, or using an editor, linter, other tool (vscode). Not sure what’s the best way to commit this to run on github CI.

Reason for this is the default tsconfig setting: lib: es2019. es2019 does not support bigints, only es2020 does. Bigints seem to work both with and without hermes; there is no necessity to use es2019 at this point.

So, not really the engine issue; but an interop.

It still reproducible on all versions.

Hey, @paulmillr – thanks for your persistence here.

To provide a bit of context, while we do get paid to work on React, historically we haven’t been able to prioritize incoming issue triage compared to the work on already confirmed issues. This may come across as bureaucratic, but it was mostly due to support being ad-hoc and dependent on individual engineers’ availability. This is something we’re working to fix. We finally have a dedicated team for managing our OSS repos/issues, and I expect this to improve this year. 🎉

We appreciate your work on Chokidar. I know doing OSS work can feel pretty thankless but you’re doing awesome work.

@paulmillr I haven’t been able to reproduce this on iOS with Hermes, RN 0.71.6, with an out-of-the-box react-native init app. I’ve also checked that production bundles are correctly minified with both terser (the new default) and uglify-es (the old one). A colleague has checked Android as well. Could you share a bit more?

@blakef

"target": "es2019",
"lib": ["es2019", "es2020.bigint"],

^ This doesn’t work for bigint literals (123n).

"target": "es2020",
"lib": ["es2019", "es2020.bigint"],

^ This works properly for bigint literals and non-literals.

Target is what defines syntax; lib defines features if i’m not mistaken.

We’ll want to be a bit careful about the choice here too - we support parts of ES2020 on all engines (after transforms), including es2020.bigint, but not others (es2020.sharedmememory?), so entirely switching to es2020 isn’t going to be quite right.

tsconfig.json allows us to pick and choose, so we’ll need to check our capabilities against the choices here: https://github.com/microsoft/TypeScript/tree/main/src/lib

@lunaleaps @rickhanlonii should both have merge permissions to https://github.com/tsconfig/bases/blob/main/bases/react-native.json

Note that, at least in the default template we provide, tsc is used for type checking, but not code generation.

Ah, that makes sense! Thanks - we’ll get that fixed.

@robhogan if you can’t reproduce, that’s another question.

On it. Will repro and ping you back.

@cortinico the repro is in the first post.

I’m developer of open-source software, which is downloaded a lot more times than React, or React native. I don’t receive $ for it. Bigints with RN have always been a problem since 2019: it’s a constant hassle for us, third party library developers, and consumes our (unpaid) time.

1. RN has already acknowledged it doesn’t fully support bigint syntax in 0.70 release notes.
2. RN has already closed the original #34603 #28492 because no one commented there for a few weeks.
3. I have provided the exact reproducible cases in the first post. It’s TWO lines of code.

If you don’t want to spend 5 minutes thinking deeply about the issue, and instead aim for bureaucracy, it’s fine, I don’t care and will simply close the issue. You receive $$$ for this. It’s not my job to work on facebook stuff for free. Big corps exploiting OSS devs is not cool. We are overwhelmed and simply want less hassle from engines which don’t implement ECMAScript syntax in full.