feat: add support for npm package#488
Conversation
|
Heavily inspired from swc and biomejs implementations. This version only installs the binary depends on the arch of user's system @tusharmath |
|
Saw the video ❤️ |
|
Can you run |
| # CD to package and publish and move back to top-level folder | ||
| run: for package in npm/*; do cd $package; npm publish --tag latest --access public --provenance; cd ../..; done | ||
| env: | ||
| NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }} |
There was a problem hiding this comment.
- Can we not publish everything together? What happens if one of the publish command fails?
- Can we log after every publish?
There was a problem hiding this comment.
If one of them fails other one continues.
Logging in the sense? Just printing that one of the package is published right?
Also by default npm would console everything related to push and the reason for push fails etc.
There was a problem hiding this comment.
Good point. npm logs should be enough.
There was a problem hiding this comment.
but ignoring error in that case could mask the problem as the ci will pass successfully and to know about problem we need to thoroughly read through logs or inspect npm packages
There was a problem hiding this comment.
we can also add an dry-run npm release workflow in order to able to test that everything works as expected especially before merging this
There was a problem hiding this comment.
We should use npm publish --workspaces command instead of looping using bash.
https://docs.npmjs.com/cli/v7/commands/npm-publish#workspaces
|
We can remove the generated files from being committed to git? |
|
Yes, we can able to run it globally too. I will update the PR with the comments you provided. Thanks. |
|
I can't able to lint.sh can you provide a doc on how to run it? Some errors it seems. |
|
There are a few other comments @b4s36t4 |
|
I think due to the difference in remote config and other issues. If you could can you please review it again?
Rest looks good to me based on previous review. |
|
Yikes!
|
| # CD to package and publish and move back to top-level folder | ||
| run: for package in npm/*; do cd $package; npm publish --tag latest --access public --provenance; cd ../..; done | ||
| env: | ||
| NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }} |
There was a problem hiding this comment.
but ignoring error in that case could mask the problem as the ci will pass successfully and to know about problem we need to thoroughly read through logs or inspect npm packages
|
@meskill Thanks for the review, it does make a lot of sense to make your suggested changes. It did came up nice and easy. Really appreciate it :) |
|
@tusharmath Please review the PR now. Let me know if there's anything missing thanks :). |
|
I don't think there are any generated files. All the package.json files are intended. https://github.com/swc-project/swc/tree/main/scripts/npm/ see this for the reference. |
|
@b4s36t4 Though SWC is committing the files to git, I don't think it's a good idea for our current setup. These files can be generated, and contain the release version in them. We will end up creating a commit everytime we make a release, which is unnecessary. |
|
Will update. |
|
@tusharmath Sorry for asking questions such lately. But As you mentioned we need to wipe/no-commit package.json files committed to github, I want to bring this attention if we delete the package.json and do this file generation with the script wouldn't that be complex? If you see we're building the tailcall for different platforms for different arch types handling these conditions inside the script would make the script a bit complex, agree? As per the comment to commit everytime the package.json we don't have to. We can keep them as a read-only files (need to remove Let me know your thoughts. |
It would be easier to manage the platforms this way. We could just configure the script to generate the package.json file for that particular platform. This is quite standard in node.js projects actually.
I am not sure why should the build script change. What I am saying is - we should write a node.js script, that generates the dirs, readme, package.json, and copy appropriate release builds for the platforms we wish to support. Those package.json should be created from a template.package.json.
You are right we don't "need" to commit. However as discussed, generating the files using a template would make it easier for us to change the meta data about the package easily. |
| "engines": { | ||
| "node": ">=14.*" | ||
| } | ||
| } |
There was a problem hiding this comment.
This should be a private package.
set private:true.
Add workspaces for each supported platform.
|
Action required: PR inactive for 2 days. |
|
Working on few other things, probably would be completing things by tomorrow. |
|
Action required: PR inactive for 2 days. |
|
PR closed after 2 days of inactivity. |
|
/tip $10 @b4s36t4 |
|
🎉🎈 @b4s36t4 has been awarded $10! 🎈🎊 |
Summary:
This PR adds support for tailcall npm package to be publishable via CI pipelines.
Issue Reference(s):
Fixes #470
/claim #470
Build & Testing:
cargo testsuccessfully../lint.shto address and fix linting issues.Checklist:
Demo
as.mp4