Maintainers - Need a hand?

[huntharo]

Detailed Description

I've got a few instances of local-npm build and running within the last few days and I've found some things that I can contribute if there is interest:

• Express Server Timeouts - Express's HTTP timeouts are incorrect by default, for example, the keep alive timeout that an incoming socket can remain idle for before being closed outside of the HTTP protocol (TCP close) is 5 seconds. That 5 seconds is far lower than most HTTP clients will default to before closing the client side of the socket (typically they expect a socket to remain idle for up to 60 seconds). This setups up a race condition where the client will see socket hangups after they sent a request if it cross the wire with the close from Express. I have the fixes in hand for this and can show how to reproduce this.
• Keep Alive on Outgoing HTTP Sockets - Additionally, Node.js does not use keep alive sockets for HTTP by default. Node also does not have a DNS cache, so this results in a DNS lookup per outgoing HTTP request on Linux by default (except on distros like Ubuntu that install a caching local name server by default - this is not a problem on Windows because Windows has a DNS cache that is used by the name resolution APIs on the platform). Node.js also has a default thread pool size of 4 for operations that call blocking methods, which include the DNS methods used to open outgoing HTTP sockets. This means that no more than 4 DNS requests can be resolved at the same time. Taken altogether, this can have a pretty detrimental impact on performance. I have the fixes in hand for this.
• Docker - I have a nice Dockerfile (runs as non-root with a mounted data volume, none of which was trivial), a docker-compose file, and instructions on how to install local-npm under docker as a systemd service. I'd like to add those files and instructions.
  • I went down the path of using Docker because A) I use Docker / kubernetes for almost everything and B) because my first attempts to build the app (even using nvm) failed and I wanted a controlled and reproducible environment.
  • Incidentally, I have my daemon of this running on a Raspberry Pi 4 using Docker.
    -.npmrc - While reading the docs on using npmrc I didn't want to install it... I am used to editing .npmrc files by hand, but I noticed that a simple .npmrc example was missing from the docs. I can add that.
• --url Docs - The docs on --url did not make it clear to me that it was necessary to set this so that the npm client will end up with the url in the package-lock.json. I can update the docs to explain the impact of passing or not passing the --url parameter.
• async/await - I converted ~95% of lib/index.js to use async/await, flattening the layers of promise nesting in the process. If this is a third rail let me know... this would not be the first PR I would make and we could discuss this more if that's helpful.
• Next Release - I'd like to work on getting a release shipped. I've maintained open source projects before (Cygwin/X - 2000-2004) and can handle making releases if desired.

I'm submitting this issue as I'd like to confirm help is desired before I start cutting PRs and that there is either someone able to release code I submit or that I can assist in the release process. I'd would love to ask some questions on a Hangout too to make sure I'm aware of some of the supported corner cases (beyond the tests) so I don't break things.

Thanks! Harold

[iainmerrick]

It certainly looks like this project is unmaintained! I've just been trying it out myself, and found it wouldn't install out of the box on macOS because its level dependency is too old—it doesn't pick up a prebuilt binary and compile from source fails.

@huntharo, if you or somebody else has the time and inclination to fork this project and properly maintain it, I'd be interested in helping out. For now I'll just make my own private fork and patch up the deps.

[gabrielcsapo]

I can give ownership if anyone wants maintainer access?

…

On Tue, Oct 26, 2021 at 10:03 AM Iain Merrick ***@***.***> wrote: It certainly looks like this project is unmaintained! I've just been trying it out myself, and found it wouldn't install out of the box on macOS because its level dependency is too old—it doesn't pick up a prebuilt binary and compile from source fails. @huntharo <https://github.com/huntharo>, if you or somebody else has the time and inclination to fork this project and properly maintain it, I'd be interested in helping out. For now I'll just make my own private fork and patch up the deps. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#190 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOE2W7RENO7VNHFEPLZSKTUI3UQRANCNFSM4UUMHRTA> .

[lirantal]

@gabrielcsapo and maintainers team,
I truly value your openness and kindness to invite and include others onto the project, however, I feel I should be that person that shouts oh no, remember the event-stream incident! to make sure we do not repeat that malicious npm package story.

Aside from inviting others to collaborate on the project, you could also point folks towards verdaccio which is actively maintained and has been steadily growing in popularity, as well as cited by npm themselves as the go-to project for npm alternatives to run locally.

Happy to help in any way I can.