Skip to content
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

I'm un-maintaining local-npm #122

Merged
merged 1 commit into from
May 15, 2016
Merged

I'm un-maintaining local-npm #122

merged 1 commit into from
May 15, 2016

Conversation

nolanlawson
Copy link
Member

From now on, there will be this little badge in the local-npm README:

project unmaintained

Also when you open new issues or PRs, the issue template will tell you it's unmaintained.

This project was fun and useful while it lasted. I've actually used it as my primary npm server on my personal MacBook for the past year. It works great.

local-npm started off as a proof-of-concept to show it was possible to easily build an npm server using PouchDB. Now it's accomplished that and a lot more.

However, the project is very ambitious, and it's currently consuming more of my time with issues, PRs, and questions than I'm reasonably able to manage. It needs work. In particular, it really ought to support private modules (#116), npm publish ought to get fixed (#118), and it should proactively download new tarballs (#102) for a truly offline experience.

At this point, though, it offers minimal benefit over --cache-min 99999999 (as I learned recently from a talk by @seldo ; thanks for setting me straight), since that trick will also (AFAICT) avoid the metadata request, as local-npm does. Now, if local-npm actually proactively downloaded newly published tarballs as it listened to the changes feed, that would make it a slam dunk, but I really don't have time to work on that.

Also, I fully expect the npm team to continue improving performance and the offline/lie-fi/slow-fi experience, so it's probably best just to put our weight behind their efforts. local-npm still stands as a useful tool for some cases (e.g. a workshop where everybody connects to one local-npm that already has the packages cached), but as a general purpose "offline npm" I don't think it makes much sense.

Thanks to everyone who filed issues and helped out, especially @calvinmetcalf who wrote a significant chunk of the daisy-chaining, tarball, and CLI logic. If anybody wants to take over this project, open up some PRs and I'll be happy to give you commit access. :)

@nolanlawson nolanlawson merged commit 909cb8f into master May 15, 2016
@nolanlawson
Copy link
Member Author

And thanks also of course to @NickColley for the logo and really every other contributor; y'all are wonderful. :)

@gr2m
Copy link

gr2m commented May 15, 2016

Thanks for the great project @nolanlawson, and I agree with all your points, time to move on <3

@jfmengels
Copy link

Thanks a lot for the project and the work you put in @nolanlawson (and others contributors). Have fun playing and maintaining other cool stuff! :)

@billiegoose
Copy link
Collaborator

I'm not so eager to let this project whither. Of all the self-hosted npmjs mirrors I've found, only this one and npm_lazy are active projects. npm-mirror, sinopia, reggie, reginabox... none have been updated in over a year. Plus, this one has a web UI. Maybe I see the project differently, because I've come to it out of a business need; npmjs.org screws up enough that I've decided I need a caching server in-datacenter for continuous integration. Briefly here's my thoughts:

it really ought to support private modules

I don't need that support, I just need a reliable mirror

npm publish ought to get fixed

Again, I guess I'm not interested in full read/write, just read.

it should proactively download new tarballs

That one would actually be really cool. Particularly in combination with my continuous integration and something like next-update.

it offers minimal benefit over --cache-min 99999999

That's just an npm install flag though, right? Wouldn't that be useless on a fresh docker image, for example? One huge advantage of running a local-npm server is that I can share the cached results between all the computers in my company. I'm also hoping that every package that any employee (or CI server) installs can be cached, so that "left-pad" style scenarios where "npm install worked yesterday, but today it doesn't" can be avoided.

Thoughts?

@calvinmetcalf
Copy link
Collaborator

@wmhilton you are welcome to start maintaining it 😄

@nolanlawson
Copy link
Member Author

Yeah I just don't have time or energy for this project anymore, sorry. Please feel free to fork or open PRs as desired.

@adriatic
Copy link

I just found this gem (reading https://addyosmani.com/blog/using-npm-offline/), so finding that is not maintained any more was a bit disappointing. However, I strongly agree with @wmhilton that

it offers minimal benefit over --cache-min 99999999

is not applicable in my scenarios for using local-npm.

What about this: if local-npm would be maintained, it would be tremendously (boy, sounding like Trump 😢 ) useful for our Monterey defined as:

Monterey is an extensible application that provides a graphical user interface for a collection of tools to simplify the creation, configuration and maintenance of Aurelia applications.

I believe that just Monterey can extend the local-npm tool life a lot, so I would be interested in finding out whether we can find a few folks (@wmhilton and @calvinmetcalf for example) that would take over the maintenance - and even more, be interested in joining Monterey development.

@billiegoose
Copy link
Collaborator

@adriatic @nolanlawson The original author and I came to an agreement to leave this project unmaintained (see the discussion here #127) and I started a fork under a new name registry-alpha. I would love to have a reason to develop it further! Tell you what, could you open an issue on registry-alpha to tell me more about Monterey's goals and how they involve registries?

@adriatic
Copy link

@wmhilton @nolanlawson My plans are even more ambitious than Will's but at this point this is not as important as knowing that npm-local "fits the bill" just as is. So, I would hate to make yet another fork and further dilute the very impressive code that Nolan created.

Given the area of interest that @wmhilton shares (list of GitHub repositories) I would not be surprised to see him (Will) to work on local-npm work we need for Monterey - and get to work on Monterey itself :-)

Will, please join me in this Gitter chat room to discuss these issues, if you are interested

@gabrielcsapo
Copy link
Member

@nolanlawson would you be interested in transferring ownership? I know PayPal has resources that would like to use this project in the future.

@billiegoose
Copy link
Collaborator

@gabrielcsapo Would you be interested in helping me out with modserv instead? It's very much the continuation of local-npm in spirit. My main priorities are maintenance (I've added support for scoped packages!) and simplification (I made a "docker run" installation option!)

@nolanlawson
Copy link
Member Author

@gabrielcsapo if you are happy with @wmhilton's fork, let me know. Otherwise I'm happy to grant either one of you or both of you maintainer privileges.

@gabrielcsapo
Copy link
Member

@nolanlawson I would still like to maintain this source project, I think there is merit in both projects

@nolanlawson
Copy link
Member Author

@gabrielcsapo Sorry for the late reply; I was taking a vacation from GitHub. You should now have full rights to this repo and to the npm package. Please do with it as you like! 😃

@gabrielcsapo
Copy link
Member

@nolanlawson you rock! Are you still open for discussion on the direction of the project?

@nolanlawson
Copy link
Member Author

nolanlawson commented May 17, 2017 via email

@gabrielcsapo
Copy link
Member

Will move to my personal repo until I get more people to maintain a standalone organization, @nolanlawson does that sound reasonable?

@nolanlawson
Copy link
Member Author

nolanlawson commented May 17, 2017 via email

@gabrielcsapo
Copy link
Member

@nolanlawson seems like I am unable to transfer it to anywhere :(

@gabrielcsapo
Copy link
Member

I created https://github.com/local-npm @nolanlawson and added you as an owner.

@nolanlawson
Copy link
Member Author

nolanlawson commented May 17, 2017 via email

@nolanlawson
Copy link
Member Author

OK, you are now an admin, forgot to give you those privileges before

@gabrielcsapo
Copy link
Member

woot woot @nolanlawson thank you!

@billiegoose
Copy link
Collaborator

OSS projects never truly die, they just become one with the Force. 😂 Such a beautiful peaceful transfer of power, I'm tearing up a little.

@gabrielcsapo
Copy link
Member

I am hoping this project and yours @wmhilton will coalesce at one point or another!

@billiegoose
Copy link
Collaborator

:) I am definitely happy to contribute to either!

I know PayPal has resources that would like to use this project in the future.

That sounds promising!

@gabrielcsapo
Copy link
Member

@wmhilton I am kind of the only resource right now :)

@adriatic
Copy link

@gabrielcsapo can you remind me what is your plan with this project?

@gabrielcsapo
Copy link
Member

@adriatic let's use this issue #134 to discuss that. If anyone else is interested I would love to hear what everyone thinks.

@gabrielcsapo gabrielcsapo deleted the unmaintain branch May 20, 2017 15:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants