Node.js Foundation Technical Steering Committee (TSC) Meeting 2018-07-18

[mhdawson]

Time

UTC Wed 18-Jul-2018 17:00 (05:00 PM):

Timezone	Date/Time
US / Pacific	Wed 18-Jul-2018 10:00 (10:00 AM)
US / Mountain	Wed 18-Jul-2018 11:00 (11:00 AM)
US / Central	Wed 18-Jul-2018 12:00 (12:00 PM)
US / Eastern	Wed 18-Jul-2018 13:00 (01:00 PM)
London	Wed 18-Jul-2018 18:00 (06:00 PM)
Amsterdam	Wed 18-Jul-2018 19:00 (07:00 PM)
Moscow	Wed 18-Jul-2018 20:00 (08:00 PM)
Chennai	Wed 18-Jul-2018 22:30 (10:30 PM)
Hangzhou	Thu 19-Jul-2018 01:00 (01:00 AM)
Tokyo	Thu 19-Jul-2018 02:00 (02:00 AM)
Sydney	Thu 19-Jul-2018 03:00 (03:00 AM)

Or in your local time:

• http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Technical%20Steering%20Committee%20(TSC)+Meeting+2018-07-18&iso=20180718T17
• or http://www.wolframalpha.com/input/?i=05PM+UTC%2C+Jul+18%2C+2018+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1Mh2ESjOvG6lbkQBuMq9N01z3cq-Y5auTxASJ2StL5jw/edit

Agenda

Extracted from tsc-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/build

• Request for elevated permissions #1337

nodejs/node

• [v10.x] Revert "http: always emit close on req and res" #21809
• Password Hashing API #21766
• doc: remove 2 unused error codes from errors.md #21491

nodejs/TSC

• Tracking issue for updating TSC on Board Meetings #476
• Strategic Initiatives - Tracking Issue #423
• Proposal: add all new core modules under a scope? (too late for http2) #389
• Move meetings times to 12,17,21 (or 12,16,21) 570

nodejs/docker-node

• Image without npm nor yarn

nodejs/user-feedback

• 2018-07-16 Public User Feedback Meeting - General User Feedback #74

Invited

• Anna Henningsen @addaleax (TSC)
• Сковорода Никита Андреевич @ChALkeR (TSC)
• Colin Ihrig @cjihrig (TSC)
• Daniel Bevenius @danbev (TSC)
• Franziska Hinkelmann @fhinkel (TSC)
• Gibson Fahnestock @gibfahn (TSC)
• Jeremiah Senkpiel @Fishrock123 (TSC)
• James M Snell @jasnell (TSC)
• Joyee Cheung @joyeecheung (TSC)
• Matteo Collina @mcollina (TSC)
• Michael Dawson @mhdawson (TSC)
• Myles Borins @MylesBorins (TSC)
• Ali Ijaz Sheikh @ofrobots (TSC)
• Rod Vagg @rvagg (TSC)
• Michaël Zasso @targos (TSC)
• Sakthipriyan Vairamani @thefourtheye (TSC)
• Timothy Gu @TimothyGu (TSC)
• Rich Trott @Trott (TSC)

Observers/Guests

Notes

The agenda comes from issues labelled with tsc-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

Zoom link: https://zoom.us/j/611357642
Regular password

Public participation

We stream our conference call straight to YouTube so anyone can listen to it live, it should start playing at https://www.youtube.com/c/nodejs+foundation/live when we turn it on. There's usually a short cat-herding time at the start of the meeting and then occasionally we have some quick private business to attend to before we can start recording & streaming. So be patient and it should show up.

Many of us will be on IRC in #node-dev on Freenode if you'd like to interact, we have a Q/A session scheduled at the end of the meeting if you'd like us to discuss anything in particular. @nodejs/collaborators in particular if there's anything you need from the TSC that's not worth putting on as a separate agenda item, this is a good place for that

[ChALkeR]

@mhdawson I think #570 also needs to be mentioned on the meeting.
I just labelled it, sorry for not doing so earlier.

[mhdawson]

@ChALkeR thanks, added.

[bnb]

I personally added the tsc-agenda label to this Docker WG issue: Image without npm nor yarn

Definitely seems like the Docker WG is going down a path that I've heard discussed quite a bit both within the project and from developers outside of the project in various communities within the ecosystem.

Since there's some demand for it at the Docker WG level and some work has already been done to achieve it, I'm curious about a few things:

• Is there work that the project can do to help assist the Docker WG in fulfilling this kind of request without needing to slice out npm from the binary?
  • I personally think the idea of an npm-less Docker image is good, but don't necessarily know if I'd be comfortable using a non-default binary in a production application. I'm concerned that there may not be a simple way for user to differentiate.
• Is shipping an additional npm-less binary possible? I can think of a few use cases (Severless, containers, IoT) where this would be a beneficial thing to do.
  – If neither of the above are possible/going to happen, will the TSC officially offer support for the Docker no-npm no-yarn image?

Tried to follow the guideline that @addaleax described in the issue, so don't hesitate to tell me if I've done something out of order here! ❤️

[targos]

I was not aware of a difference in the binary when built without npm. What is the difference?

[bnb]

@targos to the best of my understanding, it's largely around the size of the binary – if I recall correctly, npm is about ~45mb (please, someone correct me if I'm wrong!) which is why an npm-less binary is good for the use cases I mentioned (Serverless, containers, and IoT).

[targos]

@bnb The way I see it, there are:

• The node executable binary. For v10.6.0 on Linux, its size is 36MB.
• The npm module. A directory tree whose size is 30MB + two symlinks (npm and npx)

Both are part of the default distribution, but I don't think the node binary behaves differently with or without the presence of npm. It's still the same default one.

[mhdawson]

Added nodejs/Release#341 as a reference to the issue on "Image without npm nor yarn". One thing I'd still like to have better data for is the "why". I'm guessing its the download of the image and somehow there are use cases where this happens all the time. Otherwise once an image is installed and is used for the base of other images I think the cost is shared. Added to agenda for this weeks meeting as well, adding into the issue specifics of what you'd like the TSC to discuss (as requested in the issue by @addaleax would be helpful as well)

[Trott]

Regarding The Docker WG is officially chartered with the responsibility of maintaining the official Docker images. I have no qualms with them deciding (if they do) to ship a version of the image that does not bundle a package manager. I don't think there's anything for the TSC to do or worry about on this one, although I'm happy to hear things out if other TSC members disagree.

Regarding the specific questions asked by @bnb:

Is there work that the project can do to help assist the Docker WG in fulfilling this kind of request without needing to slice out npm from the binary?

Ignoring the "slice out npm from the binary" (we get to it below), the Docker WG is fully capable of surfacing work that the project can do to help assist and can ask the TSC or anyone else at any time. I'm not terribly concerned about trying to figure out any of that stuff for them.

I personally think the idea of an npm-less Docker image is good, but don't necessarily know if I'd be comfortable using a non-default binary in a production application.

If by "binary", you mean "node executable file", then there is no difference in the binary. npm is not part of the node executable. Rather, it is installed alongside the node executable. I don't think there's anything to worry about here. If people are uncomfortable running without npm, they can always use the default install. (I don't expect the Docker WG to propose shipping only Docker images that don't have package managers.)

Is shipping an additional npm-less binary possible?

Again, if by "binary", you mean "node executable file", then there is no additional binary. It's the same binary. If by "binary", you mean something else, please clarify.

If neither of the above are possible/going to happen, will the TSC officially offer support for the Docker no-npm no-yarn image?

It may be a bit ambiguous, but in my reading of the Docker WG chartered responsibilities, the decision to support a particular Docker image is essentially delegated to the Docker WG. This is not the TSC's decision to make, IMO. If we wish to override the Docker WG on this, we'd need to de-charter them. (I'll concede that reasonable people may disagree. I tend to read delegations of responsibilities in charters as broadly as I can reasonably do so, but that may not be everyone's inclination.)

In short, I don't think there's anything for the TSC to do here. (And if there is, I'm not sure it really needs to be discussed at a meeting, at least not yet. That said, I'm not suggesting that we remove it from the agenda. But if we all agree more-or-less with my assessment above, we can simply state so at the meeting and move to the next item.)

[mhdawson]

I'd be interested in talking about whether there is interest in shipping the binary on its own or if there are people who are opposed. While the docker WG can deliver a stripped down version, them having to figure out what is safe to strip out is sub-optimal. Having said that we can have that discussion in github (nodejs/Release#341) but if we do have time to poll peoples opinions in the meeting that would not be a bad thing either.

[Trott]

In a private conversation, someone pointed out that TSC doesn't seem to be terribly aware of Docker WG activities. I generally agree with this assessment. Remedies might include:

• Maybe there is a TSC member that would like to join Docker WG?
• Maybe there is a Docker WG member that would be a sensible nominee for the TSC?
• Maybe we can invite a Docker WG person to attend TSC meetings as an observer more often when there's relevant stuff being discussed?
• Maybe one or more of us can subscribe to the Docker WG repo and pay more attention. :-D

[bnb]

Again, if by "binary", you mean "node executable file", then there is no additional binary. It's the same binary. If by "binary", you mean something else, please clarify.

@Trott apologies for my lack of context on this. Most of what I mean is "shipping npm with Node.js by default". My assumption was that it gets baked into the binary, but it seems that guess was wrong.

Could you clarify for me how npm gets installed on machines when you install Node.js? Whatever the answer to that question is what I meant by "binary" 😅

[Trott]

Could you clarify for me how npm gets installed on machines when you install Node.js?

@bnb The Node.js installer (or version manager you're using or whatever) installs npm alongside node. So, for example, it might put node in /usr/local/bin/node and npm in /usr/local/bin/npm. (And, for that matter, npx in /usr/local/bin/npx.) They are all separate files.

Similarly, if you use nvm on a UNIX-like operating, try this:

ls ${HOME}/.nvm/versions/node/`node -v`/bin

You should get a directory listing with node, npm, npx, and anything you've installed as an executable with npm -g.

[Trott]

@bnb While we're at it, I'll also point out that while node is an executable binary, npm is an executable node script, and not a binary.