Looking for maintainers!

[leerob]

Hello! We're looking for maintainers to assist with this package and help close out issues and support newer versions of Node.js. I've done a fair bit of clean-up and started merging PRs, but I don't have the capacity to maintain this. I'm just trying to get the low-hanging fruit finished.

Please comment here if you're interested in helping maintain this package. Thank you!

[leerob]

Related issue: #1052

[robertsLando]

@leerob Could you make me a maintainer?

[jesec]

I am interested. I use pkg for my projects and I would like to help.

See:

https://github.com/jesec/pkg

https://github.com/jesec/pkg-fetch

[erossignon]

I could help as well.
I spent a significant amount of time getting into a deeper understanding of the virtual file system and script aggregation.
I am currently working on #1060 to support symlinks inside the virtual file system so that PKG can work when PNPM is used as a package manager.

[leerob]

I've added both @jesec and @robertsLando as maintainers. @erossignon, I've added you to help triage. Thank you, all!

I've also cut a release and can manage publishing releases in the future! 🎉

[robertsLando]

@leerob I would like to know how do you actually handle pkg-getch releases. I see in the code there is all the stuf needed to create the uploaded binaries but cannot see a github workflow for that. I would like to add support for arm32 and arm64

[jesec]

@leerob I would like to know how do you actually handle pkg-getch releases. I see in the code there is all the stuf needed to create the uploaded binaries but cannot see a github workflow for that. I would like to add support for arm32 and arm64

It is probably done manually in the past. I plan to push my GA workflows. They work very reliably so far. To do that, I would need access to vercel/pkg-fetch.

---

Multi architecture builds are going to be a bit trickier. To build a large application like Node.js runtime, one generally has to use cross compiler. That makes the workflows complicated.

Another trouble is that some distros (e.g. RHEL) don’t provide certified/official cross toolchains, so you have to either use emulation (which is very inefficient) or have a native host. I have a real arm64 machine, so I build and upload the binaries manually for this architecture.

Additionally, pkg wants to pre-generate bytecodes. To do that, pkg needs to run Node.js of the target architecture. Unfortunately, obviously binaries of different architectures are not going to work, and as a result, you would get Unable to produce bytecodes warnings and an unusable executable. Of course, you can opt out of sourceless, but that’s probably not preferred by some users. See also: #145 . My solution is to always use the new fully static variant of executables. The fully static executable would work with simple binfmt configurations without a full sysroot for that architecture.

[robertsLando]

Byt adding the new MAKE_JOB_COUNT builds are 3 times faster even on emulated archs, build took around 5 hours (instead of one entire day)

[jesec]

Byt adding the new MAKE_JOB_COUNT builds are 3 times faster even on emulated archs, build took around 5 hours (instead of one entire day)

well. everyone knows that multi threads are faster than single thread. I use os.cpus().length to detect automatically.

[leerob]

I will add you both to pkg-fetch as well!

[jesec]

I will add you both to pkg-fetch as well!

Thanks. I received an invitation but the link is not working somehow.

[robertsLando]

I use os.cpus().length to detect automatically.

Yep It's what I do also on my side, wondering if it makes sense making this default?

[robertsLando]

I will add you both to pkg-fetch as well!

Didn't received any invitation yet

[robertsLando]

Also @leerob I would keep this issue open, pin it and add the help wanted label

[jesec]

I use os.cpus().length to detect automatically.

Yep It's what I do also on my side, wondering if it makes sense making this default?

For sure. This should be the default.

Also @leerob I would keep this issue open, pin it and add the help wanted label

Of course, it would be nice to get more people to help. However, at this moment, I think we can manage to maintain this project just fine.

By the way, this issue is still pinned. We can see if we can get more replies in the next one or two weeks. After that, we should unpin this issue. Everyone: feel free to reply to this issue if you are interested.

[robertsLando]

Some questions for all maintainers:

Is there any branch protecion rule in master? I would add it if not to prevent directly push to master branch and at least one review on PR.

Also is there any commit/pr message guideline? I usually follow https://www.conventionalcommits.org/en/v1.0.0/ so we can then use tools like https://github.com/conventional-changelog/conventional-changelog to create nice looking changelogs.

Also I see we are using eslint-koplov for linting, would switch to a default lint instead (eslint standard?)

We should also consider to setup a workflow to mark as stale some old issues (and then close them if no response/activity)

How are releases handled ATM? I usually use https://github.com/release-it/release-it

[leerob]

RIght now I'm happy with the number of maintainers to start - we can add more as needed.

• Yes, there is branch protection set up
• Open to suggestions for using conventional commits. I don't have a strong opinion.
• I'm good to switch to ESLint standard set up!
• I'm handling releases using vercel/release, because NPM publish permissions are locked down

100% should mark old issues as stale. I'd love help going through old issues and closing them out.

[robertsLando]

100% should mark old issues as stale. I'd love help going through old issues and closing them out.

The stale workflow added in #1074 should make a very first cleanup

[jesec]

My opinion:

• We can encourage people to write better commit messages. However, we should not strictly enforce a certain set of rules, as that may discourage contribution. We, as maintainers, can always tweak messages of PRs as we see fit.
• eslint-koplov is the personal ruleset of the previous maintainer. I definitely agree that we should switch to more standard (not necessarily that "Standard", though) set of ESLint rules.
• I generally don't prefer automatic closing and locking of PRs/Issues, as very valid PRs/Issues can get closed because no one says "the same happens to me!" for a while, or if it is the maintainer who is unresponsive. From my experience, the practice also discourages engagements in the project, as it takes considerably more courage/efforts to open a new issue (than reply to an existing one).
• We should open Github's "Discussions", and move feature requests and other non-issue issues to there.

[robertsLando]

I generally don't prefer automatic closing and locking of PRs/Issues, as very valid PRs/Issues can get closed because no one says "the same happens to me!" for a while, or if it is the maintainer who is unresponsive. From my experience, the practice also discourages engagements in the project, as it takes considerably more courage/efforts to open a new issue (than reply to an existing one).

What that workflow does is to firslty mark the issue as stale and then if no answer is given in some weeks close it. At least all users that have opened an issue will receive a notification and will se the project is alive again and if still interested could commment back and the issue will not be closed.

We should open Github's "Discussions", and move feature requests and other non-issue issues to there.

Totally agree

[leerob]

Let's start with cutting down stale issues and then we can explore discussions! 🙏

[leerob]

You should have permissions for pkg-fetch now 👍

[leerob]

Unpinning and closing this, since y'all are doing an excellent job 😄