-
-
Notifications
You must be signed in to change notification settings - Fork 280
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
chore: fix publish secret and use correct runner os #231
Conversation
@yanyiwu @Mister-Hope review please as far as I am concerned, it is really heavy for a such simply node repo to use pnpm(it cause cannot support node<16) and rollup(it just has a ts file only, tsc or swc is enough) |
The latest change is on main. Change your target to that. The latest code on master never get published. I have emailed the original author but not getting feedback. I have no authority with settings panel and I do not have access to the pkg. If you want, you can use nodejs-jieba, that's a pkg I am maintening. |
@Mister-Hope as my pr described, use secret.GITHUB_TOKEN instead of your custom secret feel free to update or publish if u has permission |
The basic problem is that I even do not have access to publish package to npm..... |
Change your target branch to main plz, node 16 is no longer supported anymore, and we have some updates on main branch about the project. |
Edited: I believe you may also need to update permission field. |
it is long history project, many users in big companies want to use in even node@12 (include me some times), as it first supports. In my opinion if could support without more efficient, we should do it. it looks like unnecessary to do much change, keep currently and support new node napi pre-build binaries is enough let @yanyiwu decide which version should be supported, he told me would pay attention when free on weekends |
Every project should have a clear env requirement. If a project requires to be running on a non-LTS version of node.js, then they should stay on v2. Package like this with 0 reps won't met security issues from upstream. I even want v3 to be a pure esm package. Dropping old codes and moving to modern is exactly a major version should do. |
new major update without any new features is unnecessary. besides a reason why cannot use another package name instead: big companies limited connections to official npm registry or github, keep original name would help them continue use npmmirror to get prebuilt binaries |
Changes with cpp could be sync to v2 branch and ships with new v2 version, no problem for that. So no actual problem for a new major to target LTS node.js |
Why a pure esm package targeting lts with dts shipped is not "a necessary refactor" suitable for major? Also a lot of reps has major version bumped. Let's make it clear, a major bump for "node-gyp" is already worthy enough for v3 |
for declare: drop node16 support is unnecessary it should keep supporting, it is required to ship pure esm package for major release, not related to node 16 if want a pure esm major version, why not support any version supports esm if no other advantages. Currently v2 has no prebuilt binaries for node16. if could, add support to this and bump a v2 patch version please Thats why i create this pr to master not main |
Node16 is already eol, isn't it? There is no disadvantage for you to stay on v2 to use node16.
|
|
this pr fix invalid configuration of github ci test and release, including run runnings in correctly os and use github default secret token.
it should build pre-build binaries as expected and upload them to github node registry without specify token manually.