Node.js Foundation Core Technical Committee (CTC) Meeting 2017-01-25

[Trott]

Time

UTC Wed 25-Jan-2017 16:00 (04:00 PM):

Timezone	Date/Time
US / Pacific	Wed 25-Jan-2017 08:00 (08:00 AM)
US / Mountain	Wed 25-Jan-2017 09:00 (09:00 AM)
US / Central	Wed 25-Jan-2017 10:00 (10:00 AM)
US / Eastern	Wed 25-Jan-2017 11:00 (11:00 AM)
Amsterdam	Wed 25-Jan-2017 17:00 (05:00 PM)
Moscow	Wed 25-Jan-2017 19:00 (07:00 PM)
Chennai	Wed 25-Jan-2017 21:30 (09:30 PM)
Tokyo	Thu 26-Jan-2017 01:00 (01:00 AM)
Sydney	Thu 26-Jan-2017 03:00 (03:00 AM)

Or in your local time:

• http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Core%20Technical%20Committee%20(CTC)+Meeting+2017-01-25&iso=20170125T16
• or http://www.wolframalpha.com/input/?i=4pm+UTC%2C+Jan+25%2C+2017+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/15CWMkzOEeXEGqqt6S7j9cTk787azjMX2sozAdYEXm0g
• Previous Minutes Google Doc: https://docs.google.com/document/d/1Er0gdfsakYIY3Oi7ZlnKuyHrGl4_PNqGVf2BWAs6dUk

Agenda

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

nodejs/node

• [WIP] meta: update copyright statements #10599
• assert: enforce type check in deepStrictEqual #10282
• [WIP] Restore copyright attribution #10155
• lib: be robust when process global is clobbered #10135
• process: Add code to warnings, assign codes to deprecations #10116
• http: support environment-defined proxy #8381
• meta: deprecation policy #7964

nodejs/TSC

• Updating the Copyright #174

nodejs/node-eps

• Rewrite 002 - esm #39

Invited

• Anna Henningsen @addaleax (CTC)
• Bradley Meck @bmeck (observer/GoDaddy/TC39)
• Ben Noordhuis @bnoordhuis (CTC)
• Сковорода Никита Андреевич @ChALkeR (CTC)
• Chris Dickinson @chrisdickinson (CTC)
• Colin Ihrig @cjihrig (CTC)
• Evan Lucas @evanlucas (CTC)
• Jeremiah Senkpiel @Fishrock123 (CTC)
• Tracy Hinds @hackygolucky (observer/Node.js Foundation)
• Fedor Indutny @indutny (CTC)
• James M Snell @jasnell (CTC)
• Josh Gavant @joshgav (observer/Microsoft)
• Michael Dawson @mhdawson (CTC)
• Julien Gilli @misterdjules (CTC)
• Mikeal Rogers @mikeal (observer/Node.js Foundation)
• Brian White @mscdex (CTC)
• Myles Borins @MylesBorins (CTC)
• Ali Ijaz Sheikh @ofrobots (CTC)
• Jenn Turner @renrutnnej (observer/Node.js Foundation)
• Rod Vagg @rvagg (CTC)
• Seth Thompson @s3ththompson (observer/Google)
• Shigeki Ohtsu @shigeki (CTC)
• Steven R Loomis @srl295 (observer/IBM/ICU)
• Michaël Zasso @targos (CTC)
• Sakthipriyan Vairamani @thefourtheye (CTC)
• Trevor Norris @trevnorris (CTC)
• Rich Trott @Trott (CTC)

Notes

The agenda comes from issues labelled with ctc-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

Uberconference; participants should have the link & numbers, contact me if you don't.

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 CTC that's not worth putting on as a separate agenda item, this is a good place for it.

[bnoordhuis]

#10599, #10155 and #10135 can be dropped from the agenda unless there have been new developments. (#10135 I'm certain about because I didn't do anything.)

[seishun]

Maybe consider including nodejs/node#10853?

[evanlucas]

Apologies, but it's quite likely I'll be unable to attend this week. I'll be back on schedule next week. Thanks!

[Trott]

To clarify why #10282 is on the agenda, see nodejs/node#10282 (comment).

• Primary/immediate: Do we need to unlock the API to land this? (

• Secondary/longer term: I want to revisit what "Locked" means and whether assert should be locked or not. Like, shouldn't stuff like Support for comparing ES2015 Maps and Sets tape-testing/tape#342 result in someone submitting a patch making deepEqual() work as expected with Maps and Sets rather than a userland workaround? Can we at least agree that such a thing would qualify as a bug fix and not an API change? (If so, cool, I can live with that, at least certainly for now. If not, then I definitely want to argue that the API should not be locked.)

[evanlucas]

shouldn't stuff like tape-testing/tape#342 result in someone submitting a patch making deepEqual() work as expected with Maps and Sets rather than a userland workaround?

@Trott I had previously submitted a PR for that (nodejs/node#2315)

I personally think we need to figure out what we want to do with assert. We obviously can't remove it, so why not make it actually work properly. Just my opinion though.

[bnoordhuis]

I don't have a problem with unfreezing assert. Our story that assert is only for testing node itself isn't very convincing. We could simply cp lib/assert.js test/assert.js and then each version can evolve at its own pace. Given that, it makes sense to fix obvious bugs.

That said, I still think it's a good idea to encourage people to use third-party modules. Assertion testing is not a core responsibility - the plethora of testing libs shows it doesn't need to be in core - and we have to be extremely conservative. Any API design mistake is a multi-year project to fix and even bug fixes will be semver-major most of the time.

[jasnell]

I've been considering the possibility that assert could be spun off into it's own distinct module and vendored in to core as internal module.

[sam-github]

We obviously can't remove it

Sure, we can remove it. We would do this:

1. create a nodejs/assert repo
2. publish it to npmjs.org
4. re-expose it as require('assert') for backwards compatability
5. doc-deprecate it in the next major
6. runtime deprecate it in the next major after
7. delete it in the next major after

Whether we would prefer to have endless debates when people (rightly) point out its not a very good library for writing unit tests, or to just push it into npmjs where it can be developed and semvered and the ecosystem can flourish (or just stop using it and move to one of the other actively developed assertion libs) is the question.

We have a bit of a horror of removing things from node, but IMO, that kind of horror should be balanced with a stronger aversion to adding things to node. Lets not let "easy to get in - hard to get out" be our motto!

[sam-github]

@jasnell the problem with vendoring into core as a long-term strategy is it makes semver-major improvements very painful. With npm modules semver-major is NBD, no one gets hurt, though they probably will want to update sometime (or not, if the old one works and there code is stable). When we vendor into core, we force the semver changes on people updating node, even when they update node because they need some critical-to-them feature, but are now forced to eat the price of updating to the latest assert. The assert usage is probably not even in their code, but in their deps, so updating can be quite painful. Its a decent temporary strategy, but not long-term, in my opinion.

[Trott]

On the assert thing: The smallest thing we could do to get things unstuck in my opinion is to agree that modifying the assert module to deal with things like Symbols, Maps, Sets, etc. does not constitute changing the API (assuming no function signature changes). So making those sorts of fixes does not require unlocking the API etc.

(The changes may be semver-major out of caution.)

[Trott]

Let's add a quick discussion about nodejs/node#10187 (node-inspect) to the meeting.

[bnoordhuis]

It looks like I'll probably still be in transit by the time the call starts. Apologies if I don't join.

[joshgav]

suggestion: should we add a list of items tagged ctc-review to the agenda and notes? that could remind CTC members each week to review those items yet indicate that we won't spend (much) time on them in the call.

seems like we usually have a few items like that each week, nodejs/node#10970 is an example of one I might add this week, want to put it on your radar but probably don't need to discuss further today.