Session at ~Node.js~ OpenJS collaborator summit Berlin 2019

[mhdawson]

If enough members are going to be at the Collaborator summit in Berlin May 30-31 we might want to propose a session covering the work of this team.

[mhdawson]

Session Name: Package maintenance
Format: Round table discussion
Goals: Evanglise the efforts of the package maintenance team, discuss key work items, and connect with and get feedback from package maintainers.
Who should attend: Members of the package maintenance group, Node.js collaborators concerned with the use of packages with Node.js, JS package maintainers, JS project collaborators concerned with how modules are supported by their projects.
Agenda/session outline:

• outline of approach, current work and status
• agenda bashing
• follow agenda

Session leaders: Matteo Collina, Michael Dawson, (@nodejs/package-maintenance any other volunteers)
Resources to support my proposal: nothing special.

@nodejs/package-maintenance it would be good to get as many members there as possible, there is the travel fund if you need help with the cost related to travel: https://github.com/nodejs/admin/blob/master/MEMBER_TRAVEL_FUND.md

[mhdawson]

Reviewed in today's meeting seems good to everybody in attendance.

[mhdawson]

Tried to submit through form but did not show up in the list of submissions, opened this issue in the summit repo instead: openjs-foundation/summit#159

[craftninja]

Slides and feedback notes from the presentation:

https://slides.com/emilyplatzer-1/openjscollabsummitberlin2019#/

problems? support wouldn't have the same "signal" as a license separate json for support? cc-license acronyms package.json parsed every time for a module, might be an optimization to not add to package.json

do we bump major when package maintainers change their support value?

what happens when a package is abandoned and that package.json support needs to change? would need it to be republished? gross

we could have the value of support be a url

GH already supports a support.mv file?

support.json?

package specific version metadata??

how do we create solutions that are language agnostic? could we do something that has that "signal" like a license?

we could approach the OSI about this, think about a bigger scale, package.json could limit our ability to scale

sometimes there is a diff between package.json license info and physical license in the repo

maybe we solve for JS first?

there are a lot of typos and weirdness in package.json in "the wild"

**** Lets generalize our working example so it doesn't seem so Node specific (target references the Node versions)

how is the defined package.json engine and support: target different?

tidelift is doing something like this?

we are awaiting collab with maybe greenkeeper?

lower case for values? Acronyms are the only things that should be capitalized

npm-cli: there is a lot of metadata there - how many commits between releases, etc

companies that depend on a package can help maintainers (financially / with peeps?)

we are also trying to also help maintain crucial packages

watch out for companies that spin up a module and then abandon it for the community to maintain for them

when does an open source module become a company supported module? When do we pull support from a module that a company is heavily using?

mqtt.js wechat issues in chinese - translate?

tools to help validate the support levels and autogenerate those support level indicators

colophon id https://github.com/project-colophon

[Eomm]

I'm delighted to have participated to (my first) this Collaborator Summit, and I would like to share my notes.

Listening @MylesBorins explaining the ECMAScript Modules and all the special cases that this feature must support show that the edge cases are not so "edge". The main note is that there is the hypothesis to add new fields in the package.json to:

• support two types of loading (CommonJS and ESM) adding a module field that has the same purpose of main for ESM
• define the exports to expose the public API
  I think that could be related to this issue Document how to specificy non-production files in package.json. #209 since we would like to npm prune all the unnecessary files for production (this doesn't work for dynamic import.. but could be a start)
  For deepening checkout:
  https://github.com/nodejs/TSC/blob/master/Strategic-Initiatives.md

**
The insight of the OpenJS projects (impact, growth and at large) from @jorydotcom was also meaningful to understand how the organization is expanding. I wasn't able to find the slides with all the names of the project, but I think we should consider those for our analysis (for example one of those is Express.js).

**
The issues of the Inspector pointed out by @ak239 was stunning for me: he teaches me a lot in half an hour, and the work of him and all the diagnostic WG is fantastic.
This issue nodejs/diagnostics#303 was one of the most important in order to protect any possible data leaks.
We must write down a guideline also for the security context due to the implications.

**
The deprecation meeting was a great brainstorming also.
Here the output openjs-foundation/summit#153
There are many problems they need to figure out like "monkey patching" of not-documented API or how to trace the usage of the node.js.
I think that here there is many data-analysis to do to find the best solution.. and the first step is "how to collect the data".
From the package-maintenance side, we should, for sure improve our deprecation document and add some useful args and maybe collaborate if we will parse and read many "high impact" packages in next weeks.

**
The fetch "call to action" was exciting and scaring at the same time. There are some aspects to consider (behavioural and API) to add this feature in node.js core. This means to support WHATWG streams using async iterator or the pipeline API.

**
I liked a lot also the feedback from Node and the OpenJSF since it will aim to build a new site that explains how the organizations involved in the javascript world works together. I think we could contribute since this site wants to be an educational site.

**
The promise roadmap to implement these APIs is clear and in some cases, it is a "good-first-issue" to start contributing to the node.js core... mmmm interesting.
There is a BIG question mark in "how to handle multiple resolves?" To help them we could fill this questionnaire openjs-foundation/summit#175

**
Bob stream changes how the streams are used and easy the pattern from push (pause and resume) to pull base model. This is just awesome to let the community benefit from speed stream and javascript simplicity.

---

I want to say also that I have been very well during these two days. I felt part of the node.js group also if I'm a novice.
This is a great community <3
Thank you all!

[craftninja]

@Eomm : Those projects within the OpenJS Foundation are here: https://openjsf.org/projects/ . These notes are awesome!

[bnb]

This can be closed since the event is now in the past, I assume? 👍

[rxmarbles]

Seems good to me to close it.