|
| 1 | +#### Meeting from: October 30th, 2019 |
| 2 | +# Open RFC Meeting (npm) |
| 3 | + |
| 4 | +### Attendees: |
| 5 | + |
| 6 | +- Darcy Clarke (@darcyclarke) |
| 7 | +- Daniel Sauble (@djsauble) |
| 8 | +- Isaac Z. Schlueter (@isaacs) |
| 9 | +- Ruy Adorno (@ruyadorno) |
| 10 | +- Claudia Hernández (@claudiahdz) |
| 11 | +- Michael Perrotte (@mikemimik) |
| 12 | + |
| 13 | +### Agenda: |
| 14 | + |
| 15 | +- Housekeeping (introductions, outlining intentions & desired outcomes) |
| 16 | +- Review results of meeting time change poll #55 |
| 17 | +- Review Standardizing Labeling Issues & PRs as "Agenda" items |
| 18 | +- Issue: #56 [FEATURE] Create RFC for Yarn Resolutions |
| 19 | +- Issue: #14 Fix up & improve statusboard |
| 20 | +- Issue: #55 What time should we run the Open RFC calls? |
| 21 | +- Issue: #3 Add settings.yml file and extend from npm defaults |
| 22 | +- Issue: #3 Add monitoring/benchmarking tools |
| 23 | +- Issue: #2 Add funding to package.json |
| 24 | +- Issue: #1 Default template files for projects |
| 25 | +- PR: #43 Let's install peer deps again! |
| 26 | +- PR: #36 Allow script-shell config in package.json |
| 27 | +- PR: #35 rfc: @pika/pack available in stock npm |
| 28 | +- PR: #34 RFC for dependencies change script addition |
| 29 | +- PR: #24 Unpublished modules should return 410 Gone |
| 30 | +- PR: #23 Add Singleton Packages RFC. |
| 31 | +- PR: #22 Add feature to show dependencies of a particular dependency |
| 32 | +- PR: #20 powershell scripts for installed binaries |
| 33 | +- PR: #18 Interactive audit resolver |
| 34 | + |
| 35 | +#### Notes: |
| 36 | + |
| 37 | +- [2] Darcy will shift one of these calls to 2PM EST and propose another set of times for another time slot that can capture another audience. |
| 38 | +- [3] Going forward, Darcy has automated the agenda compilation for this meeting. Add the “agenda” label to issues and PRs in the CLI repo to get them added to this meeting’s agenda automatically (via a cron job). |
| 39 | +- [4] In npm@7, we intend to add better interoperability between Yarn and npm. We might not have a package-lock.json file, so the ability to use the Yarn or pnpm equivalents is important. |
| 40 | +- [4] There’s an overlapping/non-identical set of data we can get from the various files, so the plan is to have arborist be clever enough to pull what information it can and turn it into a representation of all the packages in the project. |
| 41 | +- [4] Probably a different format of the lock file that arborist can use. Not a new file in your project, but a new file in your node_modules. Format of that file tbd. |
| 42 | +- [4 ] Adding resolutions isn’t a breaking change, so we could do it in [email protected] for example. |
| 43 | +- [7] The engineering org ratified some baseline PR templates, and created a .github project which maps those templates across all of our projects. You can override them on a per-project level, so we’re creating a new settings.yml that our projects can extend from as our standard. |
| 44 | +- [7] The org-wide .github project might not be the right approach for the OSS team, not surgical enough. |
| 45 | +- [8] In addition to 100% test coverage, we want to add some benchmarks (no cache, no lockfile, etc). |
| 46 | +- [8] pnpm started a project which runs each of the package managers against the same set of scenarios, so we want to adopt this internally. |
| 47 | +- [8] We rejiggered this so it’s easier to set up scenarios, and we intend to merge it into the CLI project. In v1 we’re going to start generating results, and in v2 we intend to start comparing against other package managers. |
| 48 | +- [8] Performance of publishing isn’t super important. People don’t generally complain that publishes take too long (they complain about installs instead, because there’s a (couple) order of magnitude more operations involved). |
| 49 | +- [8] Isaacs wants this so we can benchmark npm@7 against npm@6. |
| 50 | +- [9] Ruy is shepherding the implementation of the `npm fund` command. He’s starting with examples of how we do things already in the CLI (e.g. how we open links in the browser). |
| 51 | +- [9] There are three parts, finding packages with the funding attribute set in the package.json, listing the funding URLs on the CLI, and opening individual URLs in the browser. |
| 52 | +- [10] The engineering org ratified some default templates which don’t really work for our OSS projects, so this issue is about creating a new set of default templates that all of our OSS projects can extend. |
| 53 | +- [10] This is related to (but different from) [7] |
| 54 | +- [11] This is at a point where we’ve talked through all disagreements and gathered all the data we can, so Isaac locked the issue to recognize that there’s no point in continuing to discuss. |
| 55 | +- [11] If the concerns that were brought up in the PR are real, we’ll fix them in the beta of npm@7. |
| 56 | +- [11] There’s a good chance that the first version of npm@7 that people start using widely is not 7.0, but rather 7.3. Walking back peerDependencies if needed after the npm@7 beta is available shouldn’t be a big deal. |
| 57 | +- [11] Darcy will queue up an internal discussion around this |
| 58 | +- [12] Calling the field “npm” is kind of weird since the whole package.json is technically part of npm. Should think about renaming it, or moving it to “scripts”. |
| 59 | +- [12] Potentially we could add logic where you check the .npmrc first, and if the key is not found, check your package.json (or vice-versa). |
| 60 | +- [12] The question is whether we want to respect this setting on a per-package basis. If the answer is ‘no’, we need to consider adding support for this to the packuments as well. |
| 61 | +- [12] Creating a one-off for script config will create an expectation that you can do this for other config settings as well, which seems bad. |
| 62 | +- [12] Isaacs will give this feedback on the PR and create an issue for addressing this issue in a more holistic manner. |
| 63 | +- [13] Isaacs thinks we should let this lie until post-npm@7. The team has a lot on their plate right now. Darcy is moving this to the backlog. |
| 64 | +- [14] Should bikeshed the name a bit, we don’t currently use camel casing. |
| 65 | +- [14] Other questions: when do we run the script and what information is available to it? (e.g. pre-scripts don’t know what the filename is) |
| 66 | +- [14] Isaacs doesn’t see this landing prior to npm@7, it will be an order of magnitude easier to do later. |
| 67 | +- [18] We’ve already shipped this! Isaacs moved the RFC to the implemented folder. |
0 commit comments