Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
95 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,95 @@ | ||
| #### Meeting from: October 21st, 2020 | ||
|
|
||
| # Open RFC Meeting (npm) | ||
|
|
||
| ### Attendees | ||
| - Darcy Clarke (@darcyclarke) | ||
| - Christian Siebmanns (@christian24) | ||
| - Mark Dodgson (@doddi) | ||
| - Wes Todd (@wesleytodd) | ||
| - Ruy Adorno (@ruyadorno) | ||
| - Isaac Z. Schlueter (@isaacs) | ||
| - Jordan Harband (@ljharb) | ||
| - Bradley Farias (@bmeck) | ||
|
|
||
| ### Agenda | ||
| 1. **Housekeeping** | ||
| 1. Introduction(s) | ||
| 1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct) | ||
| 1. Outline Intentions & Desired Outcomes | ||
| 1. Announcements | ||
| 1. **PR**: [#138 RFC: Add configurable data to HTTP header](https://github.com/npm/rfcs/pull/138) - @Mykyta / @doddi | ||
| 1. **PR**: [#235 Allow server generated header values](https://github.com/npm/rfcs/pull/235) - @doddi | ||
| 1. **Issue**: [#225 [RRFC] Add support to plugin dependencies.](https://github.com/npm/rfcs/issues/225) - @mshima | ||
| 1. **PR**: [#217 RFC: add registry per package per organisation](https://github.com/npm/rfcs/pull/217) - @baloran | ||
| 1. **PR**: [#121 [RFC] Added proposal for package version `link#[version](comment)` syntax](https://github.com/npm/rfcs/pull/121) - @kael-shipman | ||
| 1. **Issue**: [#155 [RRFC] Deprecated packages: automatically display dependents, to ease notifying maintainers](https://github.com/npm/rfcs/issues/155) - @dandv | ||
|
|
||
| ### Notes | ||
|
|
||
| #### Announcements | ||
|
|
||
| - More patch releases over the previous week. | ||
|
|
||
| #### **PR**: [#235 Allow server generated header values](https://github.com/npm/rfcs/pull/235) - @doddi | ||
| - Mark: It seems the idea is to leave the PR open for a while to collect more feedback, comments, etc | ||
| - Isaac: Assuming there's some way to declare headers in the config file, should the server be able to define these headers and get it auto-configured in the client? | ||
| - Isaac: It looks like this server storing headers look a lot like Cookies, we might as well just use that instead. | ||
| - Jordan: Technically Cookies seems like the way to do it but it also pose privacy concerns, GDPR, etc | ||
| - Isaac: Let's consider whether to use cookies or even if we want to do this at all. | ||
| - Action Item: Remove the item from the agenda for now and gather more feedback in PR comments. | ||
|
|
||
| #### **PR**: [#138 RFC: Add configurable data to HTTP header](https://github.com/npm/rfcs/pull/138) - @Mykyta / @doddi | ||
| - Mark: Looks like headers config is already supported by the client | ||
| - Isaac: Specifying an array of ids is not backwards compatible | ||
| - Isaac: Header configs will work in npm6 but not npm7, we could possibly put them back into the npm7 config - Meaning we could possibly implement the feature described in the RFC in a backwards compatible way with npm6 if we want to add the extra implementation in v7. | ||
| - Isaac: The following syntax should work in both npm6 and 7 once we implement it: | ||
| ``` | ||
| [header] | ||
| key=value | ||
| ``` | ||
| - Isaac: We could limit headers support to only `npmrc` config files and not support setting it through env variables | ||
| - Darcy: If someone is using the headers config the way it is today they must be using it through `npmrc` files. | ||
| - Isaac: Ooops, there might be some bugs in npm6 support. | ||
| - Darcy: Should we add it to our backlog? | ||
| - Isaac: Maybe we can queue up also the work for fixing the support in npm6. | ||
| - Darcy: We should document the proper support, only through `npmrc` files to avoid confusing users. | ||
|
|
||
| #### **Issue**: [#225 [RRFC] Add support to plugin dependencies.](https://github.com/npm/rfcs/issues/225) - @mshima | ||
| - Darcy: Looks like there are no updates since last week | ||
| - Wes: Nothing to add after last round of updates | ||
| - Ruy: Related there was the conversation of refactoring something like a `libnpmexec` for projects like Yeoman to consume | ||
| - Isaac: npx binds to so many parts of the **npm** cli that you might be better off just shelling it out to the cli | ||
| - Wes: There are lots of reasons for implements to want to avoid shelling out to a sub process and preferring a programmatic API instead | ||
| - Isaac: Getting `libnpmexec` as a sep library is a bit more tricky than it might seem | ||
| - Darcy: Action item: Create a follow-up RFC for `libnpmexec` or just backlog the work | ||
|
|
||
| #### **PR**: [#217 RFC: add registry per package per organisation](https://github.com/npm/rfcs/pull/217) - @baloran | ||
| - Wes: We chatted about it last week and it would be nice to have a concrete example of the implicit hazards this idea poses | ||
| - Wes: This potential hazard might be a big security concern for big corporations | ||
| - Isaac: If we want to make it hard for users to use this sort of feature then we might just stick with status quo and have users manually having to set it all up | ||
| - Isaac: Whenever adding new syntaxes like this we need to weight backwards compatibility, ecosystem support, etc | ||
| - Wes: Maybe find a middle ground | ||
| - Isaac: (random idea) maybe add something like a `registry:{registry}(semver)` protocol and make it so that the default is `registry:registry.npmjs.org(semver)` | ||
| - Wes: That doesn't seem to be so much of a bad idea | ||
| - Isaac: But it could potentially fragment the community | ||
| - Isaac: Have to dig more into the security hazard described by Wes in the PR comments | ||
| - Wes: We can loop back in a follow up meeting | ||
| - Isaac: Action item: Let's leave the item in the agenda, jump into the details of the security hazard brought up and consider the outcomes | ||
|
|
||
| #### **PR**: [#121 [RFC] Added proposal for package version `link#[version](comment)` syntax](https://github.com/npm/rfcs/pull/121) - @kael-shipman | ||
| - Ruy: Brought this back into the agenda since it had no activity lately and now that we have support to workspaces we could potentially just point to that as a better solution. | ||
| - Isaac: This is a great example of features that could potentially fragment the ecosystem and this is also a good example of workspaces usage. | ||
| - Wes: Think they have in mind a non-monorepo usecase | ||
| - Jordan: You could use [git submodules](https://git-scm.com/book/en/v2/Git-Tools-Submodules) today in order to support multi-repo workspaces by having submodules in your git repo pointing to the other repos | ||
| - Wes: git submodules have their own issues when working irl with large teams, etc | ||
| - Jordan: What they want is a workflow to fix up their deps, not a new package.json syntax | ||
| - Ruy: Maybe similar to what we did before, propose a subcommand tool to fix the problem rather than a new `package.json` syntax that could fragment the community | ||
| - Darcy: Leave feedback in the PR | ||
|
|
||
| #### **Issue**: [#155 [RRFC] Deprecated packages: automatically display dependents, to ease notifying maintainers](https://github.com/npm/rfcs/issues/155) - @dandv | ||
| - Isaac: It might be a little bit more challenging than originally thought but we could potentially use the `explain` feature to surface this info. | ||
| - Isaac: There are tweaks needed though since `explain` can get quite verbose and maybe slightly less helpful in this use case? Be careful so that it doesn't get super noisy. | ||
| - Darcy: Maybe a post-install notice (similar to fund) so that users can run a subcommand in order to get that info. | ||
| - Isaac: Change the install output to turn that deprecate info into a resulting item similar to audit/fund. | ||
| - Darcy: Action Item to follow up with creating a new RFC for tweaking install result to surface number of deprecation warnings (similar to audit and fund) and remove all the deprecation warnings. |