search

vercel / pkg

Package your Node.js project into an executable
https://npmjs.com/pkg
MIT License
24.32k stars 1.01k forks source link

Looking for maintainers! #1065

Closed leerob closed 3 years ago

leerob commented 3 years ago

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 commented 3 years ago

Related issue: https://github.com/vercel/pkg/issues/1052

robertsLando commented 3 years ago

@leerob Could you make me a maintainer?

jesec commented 3 years ago

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 commented 3 years ago

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 https://github.com/vercel/pkg/pull/1060 to support symlinks inside the virtual file system so that PKG can work when PNPM is used as a package manager.

leerob commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

jesec commented 3 years ago

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

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

robertsLando commented 3 years ago

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 commented 3 years ago

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

Didn't received any invitation yet

robertsLando commented 3 years ago

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

jesec commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

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

robertsLando commented 3 years ago

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 commented 3 years ago

My opinion:

robertsLando commented 3 years ago

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 commented 3 years ago

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

leerob commented 3 years ago

You should have permissions for pkg-fetch now 👍

leerob commented 3 years ago

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