Skip to content
This repository has been archived by the owner. It is now read-only.

docs: add 2017-01-11 CTC meeting notes #60

wants to merge 2 commits into from
Changes from all commits
File filter...
Filter file types
Jump to…
Jump to file
Failed to load files.


Just for now

@@ -0,0 +1,338 @@
# Node Foundation CTC Meeting 2017-01-11

## Links

* **Audio Recording**: <>
* **GitHub Issue**: [CTC#59](
* **Minutes Google Doc**:
* _Previous Minutes Google Doc:

## Present

* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Colin Ihrig @cjihrig (CTC)
* Evan Lucas @evanlucas (CTC)
* Jeremiah Senkpiel @Fishrock123 (CTC)
* James M Snell @jasnell (CTC)
* Josh Gavant @joshgav (observer/Microsoft)
* Michael Dawson @mhdawson (CTC)
* Brian White @mscdex (CTC)
* Ali Ijaz Sheikh @ofrobots (CTC)
* Seth Thompson @s3ththompson (observer/Google)
* Trevor Norris @trevnorris (CTC)
* Rich Trott @Trott (CTC)

## Standup

* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* ES modules new info
* Colin Ihrig @cjihrig (CTC)
* Opened a few PRs. libuv release. Reviewed other issues and PRs.
* Evan Lucas @evanlucas (CTC)
* cut 7.4.0
* small doc PR
* still trying to knock out passing buffer to crypto.randomBytes()
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Promises Unhandled Rejections throw PR
* Minor modules stuff
* James M Snell @jasnell (CTC)
* PR triage and landing
* HTTP/2 implementation
* WHATWG URL impl improvements
* Josh Gavant @joshgav (observer/Microsoft)
* Nothing significant this week :(
* Michael Dawson @mhdawson (CTC)
* scheduled benchmarking WG meeting this Thursday
* Configured jenkins to provide CITGM team accesx to run/modify
CITGM jobs
* ongoing work on ABI stable module API
* LTS WG meeting
* Chasing some AIX issues
* General issues review/comment/lands
* Brian White @mscdex (CTC)
* Reviewed PRs, commented on issues
* Ali Ijaz Sheikh @ofrobots (CTC)
* Triage some V8 Backports
* Seth Thompson @s3ththompson (observer/Google)
* Getting ready for V8 5.7 branch (which includes promise hooks)
* Trevor Norris @trevnorris (CTC)
* working on async hooks tests with @thlorenz
* catching up on misc issues and pr reviews
* Rich Trott @Trott (CTC)
* test, docs, tools, onboardings, mini-Code&Learn, you get the idea
* PR and issue review

## Agenda

* Landing npm 4 into node 7
* console.log and util.format should support the %i integer conversion
* timers: cleanup extraneous property on Immediates
* process: Add code to warnings, assign codes to deprecations
* meta: deprecation policy
* [WIP] meta: update copyright statements
* [WIP] Restore copyright attribution
* Updating the Copyright
* Growing the group of releasers
* Rewrite 002 - esm


## Previous Meeting Review

* Landing npm 4 into node 7
* console.log and util.format should support the %i integer conversion
* timers: cleanup extraneous property on Immediates
* doc: Deprecate old debug protocol
* [WIP] Restore copyright attribution
* process: Add code to warnings, assign codes to deprecations
* doc: Deprecate old debug protocol
* Updating the Copyright


## Minutes

### Landing npm 4 into node 7 [node#10505](

Landed in 7.4.0. Remove from agenda.

No reports of problems, some reports that “everything’s running great.”

Evan Lucas will reach out to npm to ensure they monitor their tracker for issues

**Next steps:**

- Remove from agenda.


### console.log and util.format should support the %i integer conversion [node#10292](

**Next steps:**

- Remove from agenda, continue discussion in issue.


### timers: cleanup extraneous property on Immediates [node#10205](

We called for a vote last week, it passed.

**Next steps**:

- Land.


### process: Add code to warnings, assign codes to deprecations [node#10116](

Semver-major change requires signoff from CTC.

Includes new doc page which lists all deprecations, mostly pulled from error
logs. Could be improved, but that should happen in subsequent PRs.

If you don’t object to this proposal (assigning codes to deprecations) please
note that in the thread.


### meta: deprecation policy [node#7964](

Old PR which James is picking back up to clarify deprecation policy. Please look
at and weigh in.

Requires CTC review because it’s a change to governance processes - discusses
deprecation policy, semver policies, what constitutes an internal API, etc.

There are some notable changes:
Docs-only deprecations would be considered semver-minor.
Introduces concept of “end-of-life” code for removing unused code.

@jasnell would prefer a vote to clarify consensus.


### Updating the Copyright [TSC#174](

See also:

* [WIP] meta: update copyright statements
* [WIP] Restore copyright attribution

@jasnell has formally asked for the Foundation’s legal committee to review and
provide feedback, response still pending.

Everyone should review proposed final revised form (in #10599).

Even initial reversion (#10155) requires review from legal committee.

Call for a vote (once feedback is received) to clarify consensus.


### Growing the group of releasers [CTC#48](

Doesn’t require CTC membership, but requires CTC signoff to grant release

Should shadow current releasers first to ensure they understand process.

Grant permissions after initial shadow.

Need to coordinate with Build WG.

Evan Lucas called for a vote to invite @gibfahn and @italocasas to become
releasers and grant all permissions required. Requires that their public GPG key
be promoted in release system. Also assumes completion of initial shadow.

Partial vote completed and recorded in issue.


### Rewrite 002 - esm [node-eps#39](

Talking points: <>

Current proposal ([node-eps#39]( was
made after July’s TC39 meeting. After September TC39 meeting and recent talks
with V8, we know what needs to change in next version of
on how Node.js will handle ES modules.

In September we asked for property delegation on access of imported variables
from CommonJS (CJS) modules. V8 team has misgivings on this because it would
require pessimistically guarding against all potential side effects for
accessing all imported variables, including in ESM to ESM calls. For example,
would mean none of those can be inlined.

Therefore cannot import named variables from CommonJS (CJS) modules, e.g.
`import {readfile} from “fs”`.

So CommonJS modules will provide only a namespace export with `default` and all

This comment has been minimized.


unional Feb 17, 2017

This would break most code written in TypeScript:
Please see:

This comment has been minimized.


addaleax Feb 17, 2017

@bmeck This has probably been discussed, but, like… what would speak against resolving this problem by creating an intermediate ES6 module based on the CJS exports, which just re-exports those?

properties will be accessed through that. For example:

import * as express from “express”
var app = express.default()
import express from “express”
var app = express()

Like Node.js, Babel takes `module.exports` as returned from CJS modules and uses
properties off that as imported names. Not using named variables from CJS would
therefore break Babel@6 modules too.

This means we also won’t have something like Babel@6. Newer versions of Babel
(current PR, RC for webpack2) don’t do named imports at all from CommonJS
modules; they did this because it’s the safest route, and they can reliably
depend on `default` export.

We will continue to consider other options for named imports from CJS after this
initial implementation. VM owners recognize that named imports from CJS is a
reasonable ultimate goal, but will have to wait for a later phase.

Now that we’ve decided that we can’t support named imports or Babel@6 modules as
is, we need to discuss async vs. sync loading.

Key issues: temporal dead zone problem, forwards-compatibility with the web, and
backwards-compatibility with Babel.

**Temporal Dead Zone Problem**: Exported names from CJS modules are not
definitively known till after the CJS module is evaluated, not at parse time.

ES spec guarantees that exported names are definitively known at parse time,
prior to evaluation. For example, ES specifies throwing an error at parse time
if an undefined name from an imported module is used, but for CJS modules
whether that name is defined or not cannot be absolutely determined till after

Loading file into process could be asynchronous although evaluation of the
contents is synchronous.

Async loader is to be used by web browsers and is supported by ECMA-262 as is.

Browsers maintain order of evaluation for a dependency graph, but spec doesn’t
mandate that evaluation itself be synchronous for entire dep graph. There could
be gaps during evaluation where loader can yield, which is important to prevent
browser jank.

Could support synchronization mechanism like top-level `await` around module

Supporting async module loading in Node would mean symmetry with browsers and no
need for spec change in TC39.

A synchronous loader would introduce a temporal dead zone. If CJS(1) loads ES(1)
which itself depends circularly on CJS(1), ES(1) will be evaluated first but
will have a “temporal dead zone” while waiting for CJS module to be evaluated
and guarantee existence of exported names (shape of CJS module).

With an asynchronous loader ES(1) would only be a promise, and that promise
wouldn’t be fulfilled till the next turn of the event loop, at which point the
CJS module’s evaluation will have completed. So no problem with a “temporal dead

Synchronous loaders are what Node.js has always used so behaves as previously
expected for `require`.

Would need to land a TC39 spec change which allows lazy/late finalization of
exported CJS names. This introduces a temporal dead zone (where exported
variable names from CJS modules aren’t fully guaranteed) which the spec doesn’t
currently allow (as above).

Need to decide if Node.js wants a synchronous or asynchronous loader and
advantages/disadvantages of each. Will schedule a meeting to discuss.

TC39 meeting coming up in a couple weeks, if there are concerns please raise
them with James and Bradley.

**Next steps:**

- Open an issue with summary.
- @jasnell to schedule a meeting to review.


## Q/A on public channels



## Upcoming Meetings

Node.js Foundation Calendar:

* CTC: 2017-Jan-18, 0500 UTC (9pm US Pacific)
* TSC: 2017-Jan-12, 2000 UTC (12pm US Pacific)
* Benchmarking: 2017-Jan-12, 1900 UTC (11am PST)
* Streams: 2017-Jan-12 1800 UTC (10am PST)
* HTTP2: 2017-Jan-12 1700 UTC (9am PST)

ProTip! Use n and p to navigate between commits in a pull request.
You can’t perform that action at this time.