Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal: npm advisory group #79
Form a sub-group that has the following attributes.
Will be responsible for advising npm on matters which
The group will likely need to be made up of individuals who are
As a result of point 1 under Responsibilities, there doesn't need to be any routine scheduled meetings. Instead, the group should be available through email or another channel to assist npm on matters that impact node.js and the community.
The timing of this proposal is definitely suspect, but I assure you, this isn't an indictment of any parties in regards to recent events. Instead, this proposal is written as a result of the realization that the node TSC hasn't provided a formal group to support npm. As such, the group is available to help npm when they seek advisement, but npm is in no way required to seek the advisement of the group.
Feel free to expand or alter this proposal, this isn't meant to be exhaustive, but more of a first step to get the ball rolling.
@geek Perhaps we should think a bit more broadly about how we package and deploy Node apps and their dependencies?
For example, perhaps we should reconsider the current common practice of running
Perhaps we could use a standard archive/packaging arrangement for Node apps, might be as simple as a tarball with a node_modules folder. A continuous deployment (CD) system could take care of this packaging and allow platform providers (e.g. Heroku, Modulus, Azure Web Apps) to simply deploy the prepared package rather than run
@joshgav what you are describing seems to sound an awful lot like a package manager
TQBH how people handle their apps in production is "kind of" on them. I know from talking to various friends at different orgs that there are some places that didn't feel the pain at all due to local npm mirrors that do not listen to unpublish events.
The simpler solution to what you are proposing would perhaps be to document ways that people can better prepare for deployment to production
+1, I'd say that's the first step :). I suppose I'm describing the ideal end state: an accepted industry pattern for packaging and deploying Node apps that all PaaS providers can support, and that addresses (some of) the causes of past issues with npm. Perhaps it's something Node PaaS providers like BlueMix, Modulus, and Azure Web Apps can address together.
I think this also implies we should openly document the wire protocol used by npm, if it's not documented already, and depending on how it's licensed. That would facilitate more package management tools experiments and open source projects.
To say that replacing the package manager would be non-trivial is an understatement. Until such a package manager exists and reaches a state of maturity it would not be productive to put any eggs in that basket. That said, people are free to build this now in the ecosystem without any need to be blessed by Core.
@geek I'm actually ignorant on this: Can you give examples scenarios that might require the privacy? I guess I could imagine security issues (evil version of package published)... but that seems like it would go to the security folks.. ?