-
-
Notifications
You must be signed in to change notification settings - Fork 15
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 CI auto-build #21
Conversation
Thank you! No need to lock the versions in the test Actions, they have
and I set the default to read-only, too. About the esbuild release artifact, can you help me understand what/how downstream users use it? The README has an example for creating a file that sets a global variable. This instead would be an ES module, right? It's for use as a |
The end-result would look like one in here: https://github.com/paulmillr/noble-curves/releases/tag/1.4.2 It has global variable "age". Which means it would be for plain classic |
This reverts commit 917b0b5.
I also usually do NPM publish using CI: publish-npm.yml It will build the package and upload it to NPM, using transparency logs. This would require adding NPM_PUBLISH_TOKEN to the repository. It allows to keep one less token which can be stolen from my machine. |
Based on a suggestion by @paulmillr. Closes #21
Thank you! I went for something similar (I do this a lot) based on your PR. Main differences are using two build stages to drop privileges in the one that runs esbuild (and to always upload an artifact for debugging and to notice breakages even if it's not a release), and avoiding the separate package.json. Opening an issue for NPM publishing, I would definitely like not to have this bearer token sitting around. |
Add CI auto-build:
test/build
directory using esbuildage.js
and upload it thereLock CI action commits:
Compared to 0.1.5, it's now 19x smaller: