-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Add es2020
esbuild target
#2220
Comments
I'm also getting this issue with js-ipfs. Any workaround currently?
|
I believe esbuild options can now be configured for all adapters except static, can you try and see if it works with |
Seems to work as long as the |
This works for me now, both with Thank you for adding this. Much appreciated! 🙏 |
Thanks for the confirmation. I take it that it has been resolved now, so I'll be closing this. |
Describe the problem
SvelteKit cannot build code that uses big integer literals.
Big integer literals are an
es2020
feature. Because of their design, they cannot be transpiled or polyfilled. Google's JSBI was written to address this with an option for forwards compatibility. From their READMEEsbuild cites similar reasons for leaving big integer literals untouched
In cases where a developer is authoring the code, it is possible use JSBI or an alternative. But libraries have started using the big integer literal syntax directly, and it is not possible to use these libraries with SvelteKit today. One example library is noble-ed25519, a top quality cryptography library.
Describe the proposed solution
I would like to see an option to set the esbuild target to
es2020
with SvelteKit.Reading through existing issues, changing SvelteKit to only target
es2020
would be problematic for node 12 (see discussion in #1667).One possibility would be a configurable build target. It may be possible to do this already when using
adapter-node
:kit/packages/adapter-node/index.js
Line 39 in 446c346
A more general solution would be preferable, but my use case involves
adapter-static
and I would love to see an option there if this can be solved in the adapters.Alternatives considered
Avoid libraries that use big integer literals. This would hopefully be a temporary solution. More libraries are likely to use big integer literals going forward, and the
noble
libraries that use them today are particularly high quality.Importance
would make my life easier
Additional Information
No response
The text was updated successfully, but these errors were encountered: