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

Proposal: npm advisory group #79

Closed
geek opened this Issue Mar 24, 2016 · 7 comments

Comments

Projects
None yet
5 participants
@geek
Member

geek commented Mar 24, 2016

Form a sub-group that has the following attributes.

Responsibilities

Will be responsible for advising npm on matters which

  1. npm requests advisement on
  2. impact the node community

Membership

The group will likely need to be made up of individuals who are

  1. longstanding members of the community
  2. can be entrusted with private matters that concern npm and the node community

Meetings

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.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Mar 24, 2016

Member

This is similar, although not the same, as something @othiym23 suggested, which was a Working Group under Core specifically about integrating npm into Core.

Member

mikeal commented Mar 24, 2016

This is similar, although not the same, as something @othiym23 suggested, which was a Working Group under Core specifically about integrating npm into Core.

@joshgav

This comment has been minimized.

Show comment
Hide comment
@joshgav

joshgav Mar 25, 2016

Member

@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 npm install and downloading and compiling on production instances. Those instances end up requiring a local compiler (e.g. gcc) and have to download packages at install-time from the public registry, leading to inefficiencies and past incidents. This practice also requires repeatedly downloading and compiling on each instance.

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 npm install.

Member

joshgav commented Mar 25, 2016

@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 npm install and downloading and compiling on production instances. Those instances end up requiring a local compiler (e.g. gcc) and have to download packages at install-time from the public registry, leading to inefficiencies and past incidents. This practice also requires repeatedly downloading and compiling on each instance.

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 npm install.

@MylesBorins

This comment has been minimized.

Show comment
Hide comment
@MylesBorins

MylesBorins Mar 25, 2016

Member

@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

Member

MylesBorins commented Mar 25, 2016

@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

@joshgav

This comment has been minimized.

Show comment
Hide comment
@joshgav

joshgav Mar 25, 2016

Member

@thealphanerd

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.

@mikeal

integrating npm into Core

It seems like Node should have its own package manager which is part of Core. It could be npm if npm Inc. wants that, but as I understand it they view npm as a general JavaScript package manager. Perhaps we could partner with npm Inc. and end up with a similar client for Node which implements the same protocol on the wire.

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.

Member

joshgav commented Mar 25, 2016

@thealphanerd

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.

@mikeal

integrating npm into Core

It seems like Node should have its own package manager which is part of Core. It could be npm if npm Inc. wants that, but as I understand it they view npm as a general JavaScript package manager. Perhaps we could partner with npm Inc. and end up with a similar client for Node which implements the same protocol on the wire.

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.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Mar 25, 2016

Member

It seems like Node should have its own package manager which is part of Core. It could be npm if npm Inc. wants that, but as I understand it they view npm as a general JavaScript package manager. Perhaps we could partner with npm Inc. and end up with a similar client for Node which implements the same protocol on the wire.

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.

It's also worth noting that Node.js is a generic JavaScript platform with the same scope as npm even if the identity of the project tends to be more server oriented (which is something we're working on).

Member

mikeal commented Mar 25, 2016

It seems like Node should have its own package manager which is part of Core. It could be npm if npm Inc. wants that, but as I understand it they view npm as a general JavaScript package manager. Perhaps we could partner with npm Inc. and end up with a similar client for Node which implements the same protocol on the wire.

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.

It's also worth noting that Node.js is a generic JavaScript platform with the same scope as npm even if the identity of the project tends to be more server oriented (which is something we're working on).

@williamkapke

This comment has been minimized.

Show comment
Hide comment
@williamkapke

williamkapke Mar 25, 2016

Member

can be entrusted with private matters that concern npm and the node community

@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.. ?

Member

williamkapke commented Mar 25, 2016

can be entrusted with private matters that concern npm and the node community

@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.. ?

@williamkapke

This comment has been minimized.

Show comment
Hide comment
@williamkapke

williamkapke Jan 1, 2017

Member

This has stalled and there are now groups dedicated to discussing version-management and security in the ecosystem which covers some of the topics discussed here. (but maybe not in the OP)

Closing but feel free to re-open.

Member

williamkapke commented Jan 1, 2017

This has stalled and there are now groups dedicated to discussing version-management and security in the ecosystem which covers some of the topics discussed here. (but maybe not in the OP)

Closing but feel free to re-open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment