Skip to content
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.

Sign up for GitHub

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

docs: minutes for node+js interactive meeting #6

Merged
merged 2 commits into from
Oct 16, 2018
Merged

docs: minutes for node+js interactive meeting #6

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
19210fa
docs: minutes for node+js interactive
Oct 13, 2018
28919a0
docs: add note about charter
Oct 13, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
199 changes: 199 additions & 0 deletions minutes/2018-10-12-node-interactive.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,199 @@
# Node+JS Interactive 2018 Tooling Group Session

First official meeting of the tooling working group, held as part of the
collaborator summit at Node.js interactive.

Schedule next meting [here](https://github.com/nodejs/tooling/issues/1).

## Attendance

### Chris Hiller (@boneskull):

* works for IBM.
* maintains Mocha.
* conceived of tooling working group as way to better serve Node users
writing Command Line Tools; taking into account user feedback.

### Ben Coe (@bcoe)

* PM at npm, Inc.
* maintains yargs, Istanbul, standard-version.
* has been working with Christopher and others to beter establish tooling
working group.

### Ian Sutherland (@iansu):

* maintains create-react-app.
* interested in getting involved in tooling working group.

### Guy Bedford (@guybedord)
boneskull marked this conversation as resolved.
Show resolved Hide resolved

* contributes to modules working group.
* maintains rollup, systemjs.

### Oktavianus Ludirio (@oludiro)

* works at Zillow.
* interested in learning more about writing tooling in Node.js.

### Daniel Stockman (@evocateur)

* works at Zillow.
* maintains Lerna.

### Erick Wendel (@erickwendel)

* Microsoft MVP.
* curious about tooling (would like to contribute more).

### Ruy Adorno (@ruyadorno):

* contributor to yeoman.

### Michel Lopez (@michellopez):

* senior program manager at Microsoft.
* interested in making sure Node.js/npm are stable on Windows.
* excited that Windows and Linux build times are now equivilent.

### Bryan English (@bengl)

* engineer at Intrinsic.
* interested in intersection between tooling and security (interesting challenges).

## Introduction/Mission

* *Chris*: if you had to write a bundler, or scaffolding tool, how could APIs
with Node.js make your life easier for you.
* ran user feedback session that indicated there was room for improvement
in some APIs.

## Initial Successes

* `mkdirp`:
* just landed in Node.js core.
* process of landing was a bit bumpy, due to questions around feature
detection.
* `readdir`:
* you can now fetch stat information without crossing the JavaScript C++
boundary multiple times.
* V8 Coverage:
* you can now dump coverage information directly from V8.

### What We Learned

* *Ben*: we've had some good successes, but we learned there were some
shortcomings around feature detection -- maybe we need to formalize how we
propose features to work on ... brings us to.

## Backwards Compatibility and Polyfills

* *Chris*:
* want feature detection in Node.js, but don't want to litigate it right now.
* for time being, perhaps we can get away with `process.version`.
* good start would be making pulls to community:
* update `mkdirp`, `rimraf`, based on `process.version`.
* _Michel_ also advocates this approach.

* *Daniel*:
* how do we get adoption if only cutting edge Node.js should be using?
* perhaps backporting should be goal when possible?

* *Bryan/Chris*:
* backporting is a pain in the butt, perhaps we just agree to polyfill;
see: readable stream.

* *Ruy*:
* there are good aspects to not backporting features, drive more people
to adopt new Node.js versions.

* *Ian*:
* because we're targetting CLI tools, perhaps we can be more aggressive
about pushing people to upgrade to new Node.js:

* *Daniel*:
* on topic of polyfills, `graceful-fs` is an example of
_how not to polyfill_.

* *Guy*:
* fs-extra is a better approach, doesn't mutate global fs object

we seem to have reached relative consensus that:

* we'll shim old library versions.
* won't backport to old Node.js versions.
boneskull marked this conversation as resolved.
Show resolved Hide resolved
* will use `process.version` for feature detecton.

## What other sorts of features should we be working on?

* *Chris*:
* argument parsing could be made better than `process.argv.slice(2)`.

* *Bryan*:
* would like to see `execvp` implemented, this could be a good alternative
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it a concern that the Windows process model doesn't have anything like Unix exec, so this is likely to be unix only?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @bengl ^

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sam and I ended up discussing this in person. The short answer to Sam's question is: Yes.

We may be able to do something that behaves similarly enough for the use-cases we're aiming for.

Here's how things seem to have worked (or not) in python-land (thanks Sam for sending these to me!): https://stackoverflow.com/questions/7004687/os-exec-on-windows https://bugs.python.org/issue9148

So yes it might be the case that this needs to be a UNIX-only feature (there is some precedent for UNIX-only features in Node.js).

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what is being looked for from execvp(). Since "emulation" of exec on Windows is trivial:

try{
  child_process.execSync(...);
  process.exit(0)
} catch(e) {
  process.exit(e.status)
}

its not at all useful (above is basically what python et al does).

The only thing execvp offers over execSync is true process replacement, which isn't part of the Win32 process model. I have sometimes wished for this, but since its not portable I just figured out other ways.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think some of the early feedback from the tooling user-feedback effort is that we want LESS platform specific behaviour versus more.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mhdawson Could something like execvp be implemented in a native module? Is there a precedent for something like that, where Node.js provides a hook for native modules, but no corresponding JS API surface? Is this a terrible idea?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@boneskull Depending on the complexity you want, execvp() should be pretty easy to implement as a native module, even without any hooks from Node.js. You don’t have to worry about options like environment variables or working directories, since you can set any of these from the running process before jumping into execvp(), and IPC shouldn’t be a concern either.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bengl Would that ^ work for you?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It already exists as several native module: https://www.npmjs.com/package/native-exec, https://www.npmjs.com/package/kexec, and probably more.

I'd rather see it in core so that userland native addons aren't necessary to get this done. I don't think process management functionality should be relegated to userland.

for how `npx` currently runs.

* *Guy*:
* look at the libraries that perform Windows shimming (`cross-env`, `cross-spawn`).

* *Ben*:
* I put together a list of these Windows issues which can be found here:
* https://github.com/bcoe/awesome-cross-platform-nodejs

* *Chris*:
* what if we were smarter abut path generation, and `path.separator` was
no longer a thing you needed to do.

* *Guy*:
* interesting to note that Deno does forward slashes by default.
boneskull marked this conversation as resolved.
Show resolved Hide resolved

* *Daniel*:
* whatever we build, let's avoid having runtime flags for it, e.g., forward
slashes being enabled by a flag.

* *Ben*:
* _let's step up 30,000', and talk about some of the higher level goals of the
_Tooling Initiative :tm:_.

## Action Items

* *Chris*:
* let's finish building `rimraf`. (@bcoe, @boneskull).
* let's get `mkdirp` shimmed (@iansu).
* let's figure out how we're going to approach getting further user feedback (@bcoe).
* figure out how we're announcing future meetings; blog post? (@boneskull).

* *Ben*:
* let's develop a roadmap we can share with TSC and other contributors. (@bcoe).
boneskull marked this conversation as resolved.
Show resolved Hide resolved
* let's schedule our first meeting:
* figure out roadmap first, use this to drive user feedback work.
* let's keep Windows folks in the loop, and make reducing Windows friction
an important initiative of this group (@michellopez)
* let's chat with TSC and figure out how our group interacts (@bcoe, @boneskull).

* *Guy*:
* let's reach out to library maintainers, and see how they feel about getting
their work brought into core (@guybedord).
* this could be a great way to get more Node contributors; perhaps
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dshaw it came up in the tooling meeting that it might be good to reach out to library maintainers who are interested in moving some of their work to Node.js core; might dovetail with community and mentorship work?

coordinate with Mentorship Group? (CC: @dshaw).

* *Bryan*:
* let's survey the community (@bengl, @boneskull, @bcoe).
* this can/should dovetail with community outreach/roadmap work.
* should we become an officially [chartered group](https://github.com/nodejs/TSC/blob/master/BasePolicies/Charter.md)? (@bengl, @boneskull, @bcoe)
* what are the advantages, disadvantages?

* *Daniel*:
* let's start pulling together some documentation describing what tooling
best practices currently look like in the community (@evocateur).
* we can evolve this document over time as we land work.
* in general let's better define the scope of the term tooling (@bengl, @evocateur, @michel, @boneskull):
* is it command line tools?
* is it the developer experience around APIs? (_Bryan: does crypto fall under this?_).
* is it tooling around building Node.js?

* *Michel*:
* there are new Azure images available we could use for testing,
let's see if we can get these running for Tooling group (@michellopez).
* can we get a pre-made Node development [ievm](https://github.com/xdissent/ievms)
for this initiative too? (@michellopez).