Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use bigint literals instead of BigInt constructor. #928

Closed
bhollis opened this issue Sep 30, 2023 · 6 comments · Fixed by #1063 · May be fixed by habyyb/CD-AdvancedDigitalIQ#3
Closed

Use bigint literals instead of BigInt constructor. #928

bhollis opened this issue Sep 30, 2023 · 6 comments · Fixed by #1063 · May be fixed by habyyb/CD-AdvancedDigitalIQ#3
Labels

Comments

@bhollis
Copy link
Contributor

bhollis commented Sep 30, 2023

Apologies if this has already been discussed, but looking at the output of ts-proto with --ts_proto_opt=forceLong=bigint, it uses BigInt("0") instead of 0n, which would be smaller output.

e.g.

message.myId !== BigInt("0")

vs.

message.myId !== 0n
@jcready
Copy link

jcready commented Sep 30, 2023

Just a guess: some older parsers cannot handle BigInt literals (e.g. Webpack 4's parser), but function calls work just fine :)

@bhollis
Copy link
Contributor Author

bhollis commented Sep 30, 2023

That makes sense, though isn't that more the role of Babel to generate downlevel code for older runtimes?

@stephenh
Copy link
Owner

Hi @bhollis , @jcready , I did a quick test of using 0n and looks like tsc requires a minimum runtime target in tsconfig.json to support it:

integration/map-bigint-optional/test.ts(127,17): error TS2737: BigInt literals are not available when targeting lower than ES2020.

So we could add a flag of like bigIntLiterals=true/false, maybe default it to true with the 🤞 that most users are on post-ES2020 targets.

I had started a PR to just do the find/replace:

#932

But given it needs an option to avoid breaking pre-2020 runtimes, dunno, may not be worth it?

@bhollis
Copy link
Contributor Author

bhollis commented Oct 1, 2023

Makes sense. I don't know how necessary it is, I'm just obsessed with bundle size. I can always write a Babel or Terser plugin to do the transformation.

@stephenh
Copy link
Owner

stephenh commented Oct 1, 2023

Cool; fwiw I'm going to close this out b/c I'm personally not going to work on it, but also if a PR showed up that built on #932 but moved the behavior behind a flag (or did 0n by default, and would let users get the old behavior via a flag), so that pre-2020 runtimes would not break, that'd be great, and I'd definitely accept the PR. Thanks!

@stephenh stephenh closed this as completed Oct 1, 2023
stephenh pushed a commit that referenced this issue Jun 15, 2024
Fixes #928. Since I finally got around to contributing, I figured I'd
try this old issue out too, and it was surprisingly simple. Entirely up
to you whether to trash it or not - it's not a very consequential option
and the size optimization should probably be handled by
terser/terser#1535 anyway, and it could cause
some breakage for users.

Supercedes #932.
stephenh pushed a commit that referenced this issue Jun 15, 2024
# [1.179.0](v1.178.0...v1.179.0) (2024-06-15)

### Features

* bigIntLiteral option for using BigInt literals ([#1063](#1063)) ([b89fbcb](b89fbcb)), closes [#928](#928) [#932](#932)
@stephenh
Copy link
Owner

🎉 This issue has been resolved in version 1.179.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
3 participants