You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Session at ~Node.js~ OpenJS collaborator summit Berlin 2019 #189
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.
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
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
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
**
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!
Reacted by Jory Burson, Luciano Mammino, Emily Platzer and Glenn
Activity
mhdawson commentedon Apr 12, 2019
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:
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 commentedon Apr 22, 2019
Reviewed in today's meeting seems good to everybody in attendance.
mhdawson commentedon Apr 23, 2019
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
[-]Session at Node.js collaborator summit[/-][+]Session at ~Node.js~ OpenJS collaborator summit Berlin 2019[/+]craftninja commentedon Jun 3, 2019
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-colophonEomm commentedon Jun 3, 2019
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:
modulefield that has the same purpose ofmainfor ESMexportsto expose the public APII 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 pruneall 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 OpenJSFsince 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 commentedon Jun 6, 2019
@Eomm : Those projects within the OpenJS Foundation are here: https://openjsf.org/projects/ . These notes are awesome!
bnb commentedon Jul 5, 2019
This can be closed since the event is now in the past, I assume? 👍
rxmarbles commentedon Jul 5, 2019
Seems good to me to close it.