├── .npmrc ├── .github ├── CODEOWNERS ├── ISSUE_TEMPLATE │ ├── config.yml │ └── rrfc.md ├── dependabot.yml ├── matchers │ └── tap.json ├── settings.yml ├── workflows │ ├── codeql-analysis.yml │ ├── audit.yml │ └── ci.yml └── actions │ ├── create-check │ └── action.yml │ └── install-latest-npm │ └── action.yml ├── test └── index.js ├── CODE_OF_CONDUCT.md ├── withdrawn ├── 0000-template.md ├── 0002-changelog.md ├── 0008-no-caret-prerelease-installs.md └── 0009-package-overrides.md ├── .eslintrc.js ├── .gitignore ├── LICENSE ├── SECURITY.md ├── meetings ├── 2021-10-20.md ├── 2021-11-24.md ├── 2022-07-20.md ├── 2019-09-04.md ├── 2020-03-25.md ├── 2020-06-17.md ├── 2021-09-22.md ├── 2020-04-29.md ├── 2022-06-01.md ├── 2020-04-22.md ├── 2019-12-13.md ├── 2019-10-02.md ├── 2021-01-06.md ├── 2020-03-11.md ├── 2022-02-16.md ├── 2020-06-10.md ├── 2020-08-19.md ├── 2022-02-02.md ├── 2021-02-03.md ├── 2020-07-08.md ├── 2020-09-23.md ├── 2020-07-15.md ├── 2021-09-29.md ├── 2020-05-20.md ├── 2021-11-03.md ├── 2022-05-25.md ├── 2022-06-29.md ├── 2020-10-07.md ├── 2020-11-25.md ├── 2020-02-05.md ├── 2021-12-15.md ├── 2021-10-06.md ├── 2020-01-08.md ├── 2020-05-13.md ├── 2020-03-04.md ├── 2020-12-02.md ├── 2022-02-23.md ├── 2021-03-17.md ├── 2022-01-26.md ├── 2020-07-22.md ├── 2020-08-12.md ├── 2022-08-10.md ├── 2022-06-15.md └── 2022-06-22.md ├── package.json ├── accepted ├── 0000-template.md ├── 0048-no-integrity-for-git.md ├── 0028-publish-prompt.md ├── 0047-npm-diff-ignore-cr-at-eol.md ├── 0007-publish-without-tag.md └── 0037-audit-overrides.md ├── implemented ├── 0029-add-ability-to-skip-hooks.md ├── 0043-lockfile-version-config.md ├── 0014-devoptional-shrinkwrap-flag.md ├── 0032-powershell-bins.md ├── 0039-npm-pkg.md ├── 0005-update-package-json.md ├── 0016-set-script-command.md ├── 0022-quieter-install-scripts.md └── 0010-monorepo-subdirectory-declaration.md └── CONTRIBUTING.md /.npmrc: -------------------------------------------------------------------------------- 1 | ; This file is automatically added by @npmcli/template-oss. Do not edit. 2 | 3 | package-lock=false 4 | -------------------------------------------------------------------------------- /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | # This file is automatically added by @npmcli/template-oss. Do not edit. 2 | 3 | * @npm/cli-team 4 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/config.yml: -------------------------------------------------------------------------------- 1 | # This file is automatically added by @npmcli/template-oss. Do not edit. 2 | 3 | blank_issues_enabled: true 4 | -------------------------------------------------------------------------------- /test/index.js: -------------------------------------------------------------------------------- 1 | const t = require('tap') 2 | 3 | t.test('no tests yet', async t => { 4 | // TODO: test for formatting, etc in RFCs? 5 | t.ok(1) 6 | }) 7 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | All interactions in this repo are covered by the [npm Code of 4 | Conduct](https://docs.npmjs.com/policies/conduct) 5 | 6 | The npm cli team may, at its own discretion, moderate, remove, or edit 7 | any interactions such as pull requests, issues, and comments. 8 | -------------------------------------------------------------------------------- /withdrawn/0000-template.md: -------------------------------------------------------------------------------- 1 | # Withdrawal Amendment 2 | 3 | {{This section is required for withdrawing a previously ratified RFC. Provide as much detail as possible as to why the originally drafted proposal no longer should be considered for implementation}} 4 | 5 | ## Relevant Resources 6 | 7 | {{Optional section to link relevant resources and discussions relevant to this RFCs withdrawal}} 8 | 9 | {{Original RFC}} 10 | -------------------------------------------------------------------------------- /.eslintrc.js: -------------------------------------------------------------------------------- 1 | /* This file is automatically added by @npmcli/template-oss. Do not edit. */ 2 | 3 | 'use strict' 4 | 5 | const { readdirSync: readdir } = require('fs') 6 | 7 | const localConfigs = readdir(__dirname) 8 | .filter((file) => file.startsWith('.eslintrc.local.')) 9 | .map((file) => `./${file}`) 10 | 11 | module.exports = { 12 | root: true, 13 | ignorePatterns: [ 14 | 'tap-testdir*/', 15 | ], 16 | extends: [ 17 | '@npmcli', 18 | ...localConfigs, 19 | ], 20 | } 21 | -------------------------------------------------------------------------------- /.github/dependabot.yml: -------------------------------------------------------------------------------- 1 | # This file is automatically added by @npmcli/template-oss. Do not edit. 2 | 3 | version: 2 4 | 5 | updates: 6 | - package-ecosystem: npm 7 | directory: / 8 | schedule: 9 | interval: daily 10 | target-branch: "main" 11 | allow: 12 | - dependency-type: direct 13 | versioning-strategy: increase-if-necessary 14 | commit-message: 15 | prefix: deps 16 | prefix-development: chore 17 | labels: 18 | - "Dependencies" 19 | open-pull-requests-limit: 10 20 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # This file is automatically added by @npmcli/template-oss. Do not edit. 2 | 3 | # ignore everything in the root 4 | /* 5 | 6 | !**/.gitignore 7 | !/.commitlintrc.js 8 | !/.eslint.config.js 9 | !/.eslintrc.js 10 | !/.eslintrc.local.* 11 | !/.git-blame-ignore-revs 12 | !/.github/ 13 | !/.gitignore 14 | !/.npmrc 15 | !/.prettierignore 16 | !/.prettierrc.js 17 | !/.release-please-manifest.json 18 | !/bin/ 19 | !/CHANGELOG* 20 | !/CODE_OF_CONDUCT.md 21 | !/CONTRIBUTING.md 22 | !/docs/ 23 | !/lib/ 24 | !/LICENSE* 25 | !/map.js 26 | !/package.json 27 | !/README* 28 | !/release-please-config.json 29 | !/scripts/ 30 | !/SECURITY.md 31 | !/tap-snapshots/ 32 | !/test/ 33 | !/tsconfig.json 34 | !accepted/ 35 | !implemented/ 36 | !meetings/ 37 | tap-testdir*/ 38 | !withdrawn/ 39 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | ISC License 2 | 3 | Copyright npm, Inc. 4 | 5 | Permission to use, copy, modify, and/or distribute this 6 | software for any purpose with or without fee is hereby 7 | granted, provided that the above copyright notice and this 8 | permission notice appear in all copies. 9 | 10 | THE SOFTWARE IS PROVIDED "AS IS" AND NPM DISCLAIMS ALL 11 | WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL 12 | IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO 13 | EVENT SHALL NPM BE LIABLE FOR ANY SPECIAL, DIRECT, 14 | INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES 15 | WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, 16 | WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER 17 | TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE 18 | USE OR PERFORMANCE OF THIS SOFTWARE. 19 | -------------------------------------------------------------------------------- /.github/matchers/tap.json: -------------------------------------------------------------------------------- 1 | { 2 | "//@npmcli/template-oss": "This file is automatically added by @npmcli/template-oss. Do not edit.", 3 | "problemMatcher": [ 4 | { 5 | "owner": "tap", 6 | "pattern": [ 7 | { 8 | "regexp": "^\\s*not ok \\d+ - (.*)", 9 | "message": 1 10 | }, 11 | { 12 | "regexp": "^\\s*---" 13 | }, 14 | { 15 | "regexp": "^\\s*at:" 16 | }, 17 | { 18 | "regexp": "^\\s*line:\\s*(\\d+)", 19 | "line": 1 20 | }, 21 | { 22 | "regexp": "^\\s*column:\\s*(\\d+)", 23 | "column": 1 24 | }, 25 | { 26 | "regexp": "^\\s*file:\\s*(.*)", 27 | "file": 1 28 | } 29 | ] 30 | } 31 | ] 32 | } 33 | -------------------------------------------------------------------------------- /.github/settings.yml: -------------------------------------------------------------------------------- 1 | # This file is automatically added by @npmcli/template-oss. Do not edit. 2 | 3 | repository: 4 | allow_merge_commit: false 5 | allow_rebase_merge: true 6 | allow_squash_merge: true 7 | squash_merge_commit_title: PR_TITLE 8 | squash_merge_commit_message: PR_BODY 9 | delete_branch_on_merge: true 10 | enable_automated_security_fixes: true 11 | enable_vulnerability_alerts: true 12 | 13 | branches: 14 | - name: main 15 | protection: 16 | required_status_checks: null 17 | enforce_admins: true 18 | block_creations: true 19 | required_pull_request_reviews: 20 | required_approving_review_count: 1 21 | require_code_owner_reviews: true 22 | require_last_push_approval: true 23 | dismiss_stale_reviews: true 24 | restrictions: 25 | apps: [] 26 | users: [] 27 | teams: [ "cli-team" ] 28 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/rrfc.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: RRFC 3 | about: Requesting Request For Comment 4 | title: '[RRFC] ' 5 | assignees: 6 | labels: 7 | --- 8 | 9 | <!-- 10 | # Before Opening Please... 11 | - [ ] Search for an existing/duplicate RRFC which might be relevant to your RRFC 12 | --> 13 | ## Motivation ("The Why") 14 | <!-- Examples 15 | Let us know why or how you thought of this idea. 16 | --> 17 | 18 | ### Example 19 | <!-- Examples 20 | An example of what your idea might or could do for you and others. 21 | --> 22 | 23 | ### How 24 | #### Current Behaviour 25 | <!-- Examples 26 | What is currently happening, which doesn't take care of your situation/context? 27 | --> 28 | 29 | #### Desired Behaviour 30 | <!-- Examples 31 | How would you like things to generally work to cover your situation/context? 32 | --> 33 | 34 | ### References 35 | <!-- Examples 36 | * Related/Reference to #0 37 | * Depends on #0 38 | * Blocked by #0 39 | --> 40 | * n/a 41 | -------------------------------------------------------------------------------- /.github/workflows/codeql-analysis.yml: -------------------------------------------------------------------------------- 1 | # This file is automatically added by @npmcli/template-oss. Do not edit. 2 | 3 | name: CodeQL 4 | 5 | on: 6 | push: 7 | branches: 8 | - main 9 | pull_request: 10 | branches: 11 | - main 12 | schedule: 13 | # "At 10:00 UTC (03:00 PT) on Monday" https://crontab.guru/#0_10_*_*_1 14 | - cron: "0 10 * * 1" 15 | 16 | permissions: 17 | contents: read 18 | 19 | jobs: 20 | analyze: 21 | name: Analyze 22 | runs-on: ubuntu-latest 23 | permissions: 24 | actions: read 25 | contents: read 26 | security-events: write 27 | steps: 28 | - name: Checkout 29 | uses: actions/checkout@v4 30 | - name: Setup Git User 31 | run: | 32 | git config --global user.email "npm-cli+bot@github.com" 33 | git config --global user.name "npm CLI robot" 34 | - name: Initialize CodeQL 35 | uses: github/codeql-action/init@v3 36 | with: 37 | languages: javascript 38 | - name: Perform CodeQL Analysis 39 | uses: github/codeql-action/analyze@v3 40 | -------------------------------------------------------------------------------- /SECURITY.md: -------------------------------------------------------------------------------- 1 | <!-- This file is automatically added by @npmcli/template-oss. Do not edit. --> 2 | 3 | GitHub takes the security of our software products and services seriously, including the open source code repositories managed through our GitHub organizations, such as [GitHub](https://github.com/GitHub). 4 | 5 | If you believe you have found a security vulnerability in this GitHub-owned open source repository, you can report it to us in one of two ways. 6 | 7 | If the vulnerability you have found is *not* [in scope for the GitHub Bug Bounty Program](https://bounty.github.com/#scope) or if you do not wish to be considered for a bounty reward, please report the issue to us directly through [opensource-security@github.com](mailto:opensource-security@github.com). 8 | 9 | If the vulnerability you have found is [in scope for the GitHub Bug Bounty Program](https://bounty.github.com/#scope) and you would like for your finding to be considered for a bounty reward, please submit the vulnerability to us through [HackerOne](https://hackerone.com/github) in order to be eligible to receive a bounty award. 10 | 11 | **Please do not report security vulnerabilities through public GitHub issues, discussions, or pull requests.** 12 | 13 | Thanks for helping make GitHub safe for everyone. 14 | -------------------------------------------------------------------------------- /.github/workflows/audit.yml: -------------------------------------------------------------------------------- 1 | # This file is automatically added by @npmcli/template-oss. Do not edit. 2 | 3 | name: Audit 4 | 5 | on: 6 | workflow_dispatch: 7 | schedule: 8 | # "At 08:00 UTC (01:00 PT) on Monday" https://crontab.guru/#0_8_*_*_1 9 | - cron: "0 8 * * 1" 10 | 11 | permissions: 12 | contents: read 13 | 14 | jobs: 15 | audit: 16 | name: Audit Dependencies 17 | if: github.repository_owner == 'npm' 18 | runs-on: ubuntu-latest 19 | defaults: 20 | run: 21 | shell: bash 22 | steps: 23 | - name: Checkout 24 | uses: actions/checkout@v4 25 | - name: Setup Git User 26 | run: | 27 | git config --global user.email "npm-cli+bot@github.com" 28 | git config --global user.name "npm CLI robot" 29 | - name: Setup Node 30 | uses: actions/setup-node@v4 31 | id: node 32 | with: 33 | node-version: 22.x 34 | check-latest: contains('22.x', '.x') 35 | - name: Install Latest npm 36 | uses: ./.github/actions/install-latest-npm 37 | with: 38 | node: ${{ steps.node.outputs.node-version }} 39 | - name: Install Dependencies 40 | run: npm i --ignore-scripts --no-audit --no-fund --package-lock 41 | - name: Run Production Audit 42 | run: npm audit --omit=dev 43 | - name: Run Full Audit 44 | run: npm audit --audit-level=none 45 | -------------------------------------------------------------------------------- /meetings/2021-10-20.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: October 20th, 2021 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Isaac Z. Schlueter (@isaacs) 8 | - Matt Hayes (@mysterycommand) 9 | - Owen Buckley (@thescientist13) 10 | - Michael Perrotte (@mikemimik) 11 | - Jordan Harband (@ljharb) 12 | 13 | ### Previously... 14 | 15 | - [2021-10-13](https://github.com/npm/rfcs/blob/latest/meetings/2021-10-13.md) 16 | 17 | ### Agenda 18 | 19 | 1. **Housekeeping** 20 | 1. Introduction(s) 21 | 1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct) 22 | 1. Outline Intentions & Desired Outcomes 23 | 1. Announcements 24 | 1. **Issue**: [#477 Multi-app Monorepo Followup](https://github.com/npm/rfcs/issues/477) - @mysterycommand 25 | 26 | ### Notes 27 | 28 | #### **Issue**: [#477 Multi-app Monorepo Followup](https://github.com/npm/rfcs/issues/477) - @mysterycommand 29 | - @mysterycommand 30 | - wondering if we need an owner for the action items 31 | - looks like there's a bug in the `npm-packlist` implementation as the "hacky" workaround doesn't work 32 | - @isaacs 33 | - looks like we're not properly defining the type of dep 34 | - **Action:** 35 | - @mysterycommand to write initial draft of RFC for running workspace's `prepare` scripts during pack (/cc @mikemimik) 36 | - @ljharb to write initial draft of workspace layout RFC (/cc @mikemimik) 37 | 38 | ### Other Topics 39 | 40 | #### Installing a workspace into another workspace 41 | - @mikemimic 42 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "@npmcli/rfcs", 3 | "version": "1.0.0", 4 | "description": "npm CLI rfcs", 5 | "main": "index.js", 6 | "private": true, 7 | "scripts": { 8 | "lint": "npm run eslint", 9 | "postlint": "template-oss-check", 10 | "template-oss-apply": "template-oss-apply --force", 11 | "lintfix": "npm run eslint -- --fix", 12 | "snap": "tap", 13 | "test": "tap", 14 | "posttest": "npm run lint", 15 | "eslint": "eslint \"**/*.{js,cjs,ts,mjs,jsx,tsx}\"" 16 | }, 17 | "repository": { 18 | "type": "git", 19 | "url": "git+https://github.com/npm/rfcs.git" 20 | }, 21 | "keywords": [], 22 | "author": "GitHub Inc.", 23 | "license": "ISC", 24 | "bugs": { 25 | "url": "https://github.com/npm/rfcs/issues" 26 | }, 27 | "homepage": "https://github.com/npm/rfcs#readme", 28 | "files": [ 29 | "bin/", 30 | "lib/" 31 | ], 32 | "engines": { 33 | "node": ">=18.0.0" 34 | }, 35 | "templateOSS": { 36 | "//@npmcli/template-oss": "This file is partially managed by @npmcli/template-oss. Edits may be overwritten.", 37 | "version": "4.28.1", 38 | "windowsCI": false, 39 | "macCI": false, 40 | "allowPaths": [ 41 | "accepted/", 42 | "implemented/", 43 | "meetings/", 44 | "withdrawn/" 45 | ], 46 | "rootRepo": { 47 | "add": { 48 | ".github/ISSUE_TEMPLATE/bug.yml": false, 49 | ".commitlintrc.js": false 50 | } 51 | } 52 | }, 53 | "tap": { 54 | "nyc-arg": [ 55 | "--exclude", 56 | "tap-snapshots/**" 57 | ] 58 | }, 59 | "devDependencies": { 60 | "@npmcli/eslint-config": "^6.0.0", 61 | "@npmcli/template-oss": "4.28.1", 62 | "tap": "^16.3.2" 63 | } 64 | } 65 | -------------------------------------------------------------------------------- /.github/actions/create-check/action.yml: -------------------------------------------------------------------------------- 1 | # This file is automatically added by @npmcli/template-oss. Do not edit. 2 | 3 | name: 'Create Check' 4 | inputs: 5 | name: 6 | required: true 7 | token: 8 | required: true 9 | sha: 10 | required: true 11 | check-name: 12 | default: '' 13 | outputs: 14 | check-id: 15 | value: ${{ steps.create-check.outputs.check_id }} 16 | runs: 17 | using: "composite" 18 | steps: 19 | - name: Get Workflow Job 20 | uses: actions/github-script@v7 21 | id: workflow 22 | env: 23 | JOB_NAME: "${{ inputs.name }}" 24 | SHA: "${{ inputs.sha }}" 25 | with: 26 | result-encoding: string 27 | script: | 28 | const { repo: { owner, repo}, runId, serverUrl } = context 29 | const { JOB_NAME, SHA } = process.env 30 | 31 | const job = await github.rest.actions.listJobsForWorkflowRun({ 32 | owner, 33 | repo, 34 | run_id: runId, 35 | per_page: 100 36 | }).then(r => r.data.jobs.find(j => j.name.endsWith(JOB_NAME))) 37 | 38 | return [ 39 | `This check is assosciated with ${serverUrl}/${owner}/${repo}/commit/${SHA}.`, 40 | 'Run logs:', 41 | job?.html_url || `could not be found for a job ending with: "${JOB_NAME}"`, 42 | ].join(' ') 43 | - name: Create Check 44 | uses: LouisBrunner/checks-action@v1.6.0 45 | id: create-check 46 | with: 47 | token: ${{ inputs.token }} 48 | sha: ${{ inputs.sha }} 49 | status: in_progress 50 | name: ${{ inputs.check-name || inputs.name }} 51 | output: | 52 | {"summary":"${{ steps.workflow.outputs.result }}"} 53 | -------------------------------------------------------------------------------- /accepted/0000-template.md: -------------------------------------------------------------------------------- 1 | # {{TITLE: a human-readable title for this RFC!}} 2 | 3 | ## Summary 4 | 5 | {{A concise, one-paragraph description of the change.}} 6 | 7 | ## Motivation 8 | 9 | {{Why are we doing this? What pain points does this resolve? What use cases does it support? What is the expected outcome? Use real, concrete examples to make your case!}} 10 | 11 | ## Detailed Explanation 12 | 13 | {{Describe the expected changes in detail, }} 14 | 15 | ## Rationale and Alternatives 16 | 17 | {{Discuss 2-3 different alternative solutions that were considered. This is required, even if it seems like a stretch. Then explain why this is the best choice out of available ones.}} 18 | 19 | ## Implementation 20 | 21 | {{Give a high-level overview of implementation requirements and concerns. Be specific about areas of code that need to change, and what their potential effects are. Discuss which repositories and sub-components will be affected, and what its overall code effect might be.}} 22 | 23 | {{THIS SECTION IS REQUIRED FOR RATIFICATION -- you can skip it if you don't know the technical details when first submitting the proposal, but it must be there before it's accepted}} 24 | 25 | ## Prior Art 26 | 27 | {{This section is optional if there are no actual prior examples in other tools}} 28 | 29 | {{Discuss existing examples of this change in other tools, and how they've addressed various concerns discussed above, and what the effect of those decisions has been}} 30 | 31 | ## Unresolved Questions and Bikeshedding 32 | 33 | {{Write about any arbitrary decisions that need to be made (syntax, colors, formatting, minor UX decisions), and any questions for the proposal that have not been answered.}} 34 | 35 | {{THIS SECTION SHOULD BE REMOVED BEFORE RATIFICATION}} 36 | -------------------------------------------------------------------------------- /implemented/0029-add-ability-to-skip-hooks.md: -------------------------------------------------------------------------------- 1 | # Add the ability to skip pre- and post hooks when running a script 2 | 3 | ## Summary 4 | 5 | Today, when running any `npm` script, there is no way to skip a script's pre and/or post hook. I'd like this to be changed. 6 | 7 | ## Motivation 8 | 9 | When running `npm install` today, it's very easy to ignore any `postinstall` scripts, for example, by using the `--ignore-scripts` option. When using `npm test` (which, on first glance, seems like a top-level command as well) however, the same does not work. 10 | Additionally, if for example you have a `pretest` script defined such as `"pretest": "npm run lint"` but you would want to run skip linting this time for whatever reason, that is not possible other than completely removing the `pretest` script from `package.json` temporarily. 11 | 12 | ## Detailed Explanation 13 | 14 | I would suggest to change the behavior of the `--ignore-scripts` option to also skip the `pre` and `post` hooks of a given command. 15 | To me, this would feel consistent with the behavior of how the flag works with `npm install` already today. It would establish the semantics as "run only the command/script I specified, nothing else". 16 | 17 | ## Rationale and Alternatives 18 | 19 | Instead, we could add a separate flags `--ignore-hooks` (or similar). This would have the benefit that it does not alter the existing behavior of `--ignore-scripts`. It would however be difficult to come up with a descriptive name for this new option and I'd imagine the differences and superficial overlap with `--ignore-scripts` be difficult to explain and not intuitive to understand. 20 | 21 | Alternatively, we can just not change anything and rely on users manually editing their `package.json` 22 | 23 | ## Implementation 24 | 25 | _skipped for the moment_ 26 | -------------------------------------------------------------------------------- /meetings/2021-11-24.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: November 24th, 2021 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Nathan Fritz (@fritzy) 8 | - Nathan LaFreniere (@nlf) 9 | - Gar (@wraithgar) 10 | - Owen Buckley (@thescientist13) 11 | 12 | ### Previously... 13 | 14 | - [2021-11-17](https://github.com/npm/rfcs/blob/latest/meetings/2021-11-17.md) 15 | 16 | ### Agenda 17 | 18 | 1. **Housekeeping** 19 | 1. Introduction(s) 20 | 1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct) 21 | 1. Outline Intentions & Desired Outcomes 22 | 1. Announcements 23 | 1. **PR**: [#488 Make npm install scripts opt-in](https://github.com/npm/rfcs/pull/488) - @tolmasky 24 | 1. **PR**: [#481 RFC: Run `prepare` Scripts for Linked Bundled Dependencies](https://github.com/npm/rfcs/pull/481) - @mysterycommand 25 | 1. **PR**: [#375 Define which dependencies are shared among workspace projects](https://github.com/npm/rfcs/pull/375) - @isaacs 26 | 27 | ### Notes 28 | 29 | #### **PR**: [#488 Make npm install scripts opt-in](https://github.com/npm/rfcs/pull/488) - @tolmasky 30 | - Research is ongoing into usage of & impact of transitively depended on packages that utilize install scripts 31 | - No other updates 32 | 33 | #### **PR**: [#481 RFC: Run `prepare` Scripts for Linked Bundled Dependencies](https://github.com/npm/rfcs/pull/481) - @mysterycommand 34 | - @wraithgar 35 | - this problem seems similar to git deps not running lifecycle scripts (ref. https://github.com/npm/cli/issues/3800) 36 | - No other updates 37 | 38 | #### **PR**: [#375 Define which dependencies are shared among workspace projects](https://github.com/npm/rfcs/pull/375) - @isaacs 39 | - Vincent Bailley (implementing Isolated Mode) is on vacation 40 | - Isaacs (writing RFC) is on vacation 41 | - No updates 42 | -------------------------------------------------------------------------------- /.github/actions/install-latest-npm/action.yml: -------------------------------------------------------------------------------- 1 | # This file is automatically added by @npmcli/template-oss. Do not edit. 2 | 3 | name: 'Install Latest npm' 4 | description: 'Install the latest version of npm compatible with the Node version' 5 | inputs: 6 | node: 7 | description: 'Current Node version' 8 | required: true 9 | runs: 10 | using: "composite" 11 | steps: 12 | # node 10/12/14 ship with npm@6, which is known to fail when updating itself in windows 13 | - name: Update Windows npm 14 | if: | 15 | runner.os == 'Windows' && ( 16 | startsWith(inputs.node, 'v10.') || 17 | startsWith(inputs.node, 'v12.') || 18 | startsWith(inputs.node, 'v14.') 19 | ) 20 | shell: cmd 21 | run: | 22 | curl -sO https://registry.npmjs.org/npm/-/npm-7.5.4.tgz 23 | tar xf npm-7.5.4.tgz 24 | cd package 25 | node lib/npm.js install --no-fund --no-audit -g ..\npm-7.5.4.tgz 26 | cd .. 27 | rmdir /s /q package 28 | - name: Install Latest npm 29 | shell: bash 30 | env: 31 | NODE_VERSION: ${{ inputs.node }} 32 | working-directory: ${{ runner.temp }} 33 | run: | 34 | MATCH="" 35 | SPECS=("latest" "next-10" "next-9" "next-8" "next-7" "next-6") 36 | 37 | echo "node@$NODE_VERSION" 38 | 39 | for SPEC in ${SPECS[@]}; do 40 | ENGINES=$(npm view npm@$SPEC --json | jq -r '.engines.node') 41 | echo "Checking if node@$NODE_VERSION satisfies npm@$SPEC ($ENGINES)" 42 | 43 | if npx semver -r "$ENGINES" "$NODE_VERSION" > /dev/null; then 44 | MATCH=$SPEC 45 | echo "Found compatible version: npm@$MATCH" 46 | break 47 | fi 48 | done 49 | 50 | if [ -z $MATCH ]; then 51 | echo "Could not find a compatible version of npm for node@$NODE_VERSION" 52 | exit 1 53 | fi 54 | 55 | npm i --prefer-online --no-fund --no-audit -g npm@$MATCH 56 | - name: npm Version 57 | shell: bash 58 | run: npm -v 59 | -------------------------------------------------------------------------------- /meetings/2022-07-20.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: July 20th, 2022 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Gar (@wraithgar) 8 | - Jon Jensen (@jenseng) 9 | - Owen Buckley (@thescientist) 10 | - David Zearing (@dzearing) 11 | - Luke Karrys @lukekarrys) 12 | 13 | ### Agenda 14 | 15 | 1. **Housekeeping** 16 | 1. Introduction(s) 17 | 1. Code of Conduct Acknowledgement 18 | 1. Outline Intentions & Desired Outcomes 19 | 1. Announcements 20 | 1. **PR**: [#595 Propose backwards-compatible improvements to compression](https://github.com/npm/rfcs/pull/595) - @EvanHahn 21 | 1. **PR**: [#593 Only Registry Tarballs](https://github.com/npm/rfcs/pull/593) - @thescientist13 22 | 1. **PR**: [#23 Add Singleton Packages RFC.](https://github.com/npm/rfcs/pull/23) - @usergenic 23 | 24 | #### To Ratify 25 | - **PR**: [#591 RFC: Registry-scoped keyfile / certfile credential options](https://github.com/npm/rfcs/pull/591) - `@jenseng` 26 | - **PR**: [#564 RFC: Dependency Selector Syntax & `npm query`](https://github.com/npm/rfcs/pull/564) - `@darcyclarke` 27 | - **Issue**: [#438 [RRFC] Add libc fields to select optionalDependencies should be installed or skipped](https://github.com/npm/rfcs/issues/438) - `@Brooooooklyn` 28 | 29 | ### Notes 30 | 31 | #### **PR**: [#595 Propose backwards-compatible improvements to compression](https://github.com/npm/rfcs/pull/595) - @EvanHahn 32 | - No Update 33 | 34 | #### **PR**: [#593 Only Registry Tarballs](https://github.com/npm/rfcs/pull/593) - @thescientist13 35 | - @thescientist123 36 | - started to play with `npm query` 37 | - wss looking at what query would match the right sey 38 | - @darcyclarke 39 | - `npm query ":root > *:not(:type(git))"` 40 | - @wraithgar 41 | - `npm query`'s `:not` should be able to handle most usecases for negation 42 | - community should be able to self-serve in most cases 43 | - we'll consider priveledging queries on a case-by-case basis 44 | 45 | #### **PR**: [#23 Add Singleton Packages RFC](https://github.com/npm/rfcs/pull/23) - @usergenic 46 | - [npm-audit-resolver](https://github.com/naugtur/npm-audit-resolver) might be leveraged 47 | - an interactive resolve mode for `npm audit fix` 48 | - writeup on peer painpoints here https://hackmd.io/@dzearing/BJifNnpsq 49 | -------------------------------------------------------------------------------- /accepted/0048-no-integrity-for-git.md: -------------------------------------------------------------------------------- 1 | # Stop storing `integrity` for git dependencies 2 | 3 | ## Summary 4 | 5 | We intend to stop storing the `integrity` field for dependencies installed from git. 6 | 7 | ## Motivation 8 | 9 | Our integrity calculation and verification process looks at the final, compressed, result from packing a package. This raises issues because of potential platform and architecture differences in `zlib`. 10 | 11 | ## Detailed Explanation 12 | 13 | When we install a git dependency, we clone the repository (or in some cases download an archive of the code, and extract it), we then install its dependencies and `npm pack` the resulting directory. That directory is then installed, and its integrity calculated and stored in the `package-lock.json`. 14 | 15 | Due to the nature of compression, however, we are not guaranteed to generate a byte-identical result across platforms and operating systems, even if we have the exact same input. This leads to problems where multiple members of a team could receive `invalid checksum` errors for git dependencies. 16 | 17 | ## Rationale and Alternatives 18 | 19 | To my knowledge there is no form of compression that guarantees idempotent results. That leaves us with a few options: 20 | 21 | 1. We remove the `integrity` calculation and verification for git dependencies. 22 | 2. We calculate the integrity of the package based on the `.tar` file before compression. 23 | 24 | Due to option 2 being a very significant change to npm, and not being backwards compatible (i.e. packages published by an npm with this change would not be verifiable when installed with older versions of npm), it is an untenable approach at this time. 25 | 26 | ## Implementation 27 | 28 | The `pacote` flow for git dependencies will be altered such that an `integrity` is never calculated, we will then ensure that `@npmcli/arborist` does not attempt to store the `integrity` field. 29 | 30 | ## Prior Art 31 | 32 | None to my knowledge. 33 | 34 | ## Unresolved Questions and Bikeshedding 35 | 36 | This change alters the security posture of npm with regards to git based dependencies. By not storing the `integrity` field, we have removed a layer of defense against the possibility of a git repository becoming compromised and a known hash and/or tag becoming overwritten. Is this risk acceptable? 37 | -------------------------------------------------------------------------------- /implemented/0043-lockfile-version-config.md: -------------------------------------------------------------------------------- 1 | # Add `lockfile-version` Config Flag 2 | 3 | ## Summary 4 | 5 | Currently npm 7 can read `package-lock.json` versions 1, 2, and 3, but it 6 | always writes version 2. It would be nice if npm 7 could write 7 | `package-lock.json` version 3 instead. 8 | 9 | ## Motivation 10 | 11 | npm 7 introduces new features which aren’t compatible with older npm 12 | versions, such as workspaces. This makes npm 7 a minimum requirement for a 13 | project. 14 | 15 | Both `package-lock.json` version 1 and 3 files can be huge. 16 | `package-lock.json` 2 is an intermediate format whose goal is to add 17 | backwards compatibility with `package-lock.json` version 1 and npm 6. It 18 | does so by writing both the dependency trees in the version 1 and 3 19 | formats. This means the file is even twice as big as it needs to be. This 20 | also means the same change appears twice in a diff, but in a different 21 | format, meaning it needs to be reviewed twice. This is unnecessary if the 22 | minimal required npm version is 7. 23 | 24 | Additionally, on projects where both npm v6 and v7 may be used, it would be 25 | preferable to keep the lockfile at version 1, to prevent unnecessary churn 26 | in the source tree, as both npm versions attempt to convert the lockfile to 27 | their format. 28 | 29 | ## Detailed Explanation 30 | 31 | npm is expected to output the version of `package-lock.json` which is 32 | configured in the `lockfile-version` config. This also will be the version 33 | used for `npm-shrinkwrap.json` files, following the same logic. 34 | 35 | `lockfile-version` is a standard npm config optional, and can be set on the 36 | command line, in the environment, or in any of the `npmrc` files that npm 37 | handles. It may take the possible values of `1`, `2`, `3`, and `null`, 38 | with `null` being the default. 39 | 40 | If set to a valid number, that lockfile version is used. 41 | 42 | If set to `null`, then: 43 | 44 | - Lockfiles of version 1 will be upgraded to version 2. 45 | - Lockfiles of version 2 and higher will be saved back in their current 46 | version. 47 | 48 | New major npm versions may drop support for old formats, add new supported 49 | versions, or upgrade older lockfile versions to their new defaults. 50 | 51 | ## Implementation 52 | 53 | - Add `lockfileVersion` option in `@npmcli/arborist` 54 | - Default config with valid values in npm/cli config definitions. 55 | -------------------------------------------------------------------------------- /meetings/2019-09-04.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: September 4th, 2019 2 | # Open RFC Meeting (npm) 3 | 4 | ### Attendees: 5 | 6 | - Darcy Clarke (@darcyclarke) 7 | - Isaac Z. Schlueter (@isaacs) 8 | - Claudia Hernández (@claudiahdz) 9 | - Tierney Cyren (@bnb) 10 | - Wes Todd (@wesleytodd) 11 | - Andrew Eleunterio 12 | 13 | ### Agenda: 14 | 15 | - Welcome & Introductions 16 | - #43 Peer dependencies installation 17 | - #47 Unlisted dependency support 18 | - Review/converse on sustainability & support drafts 19 | - Carry-over: #1 Display package size information postinstall 20 | - Carry-over: #48 Link .hook scripts 21 | - Carry-over: #27 Package overrides 22 | - Carry-over: #36 Script-shell config 23 | 24 | ### Notes: 25 | 26 | 1. Welcome & Introductions 27 | Tierney: Want to discuss RFCs accepted but not implemented 28 | Isaac: How do we address backlog of RFCs (including ratification) 29 | Next steps: 30 | Darcy to create an issue on npm/rfcs to highlight & discuss acceptance criteria (ie. ratification) & backlog 31 | 32 | 2. #43 Peer dependencies installation 33 | 34 | Tierney: Issues with how npm handled ordering (ex. acorn deduping/resolution) 35 | Isaac: Options... 36 | Potentially open to other RFC around singletons 37 | should identify dependencies vs. 38 | package identifier (ie. https://github.com/npm/rfcs/pull/23/) 39 | Tierney: Potentially hide features behind feature flags to play nice with pnpm, yarn etc. 40 | Isaac: `--auto-install-peer-deps` -esque flag 41 | Next steps: 42 | Modifications coming to RFC (Isaac) 43 | Support might be able to land with npm v7 44 | 45 | 3. #47 Unlisted dependency support 46 | 47 | Isaac: 48 | Don’t want to break other package managers (ex. pnpm) 49 | Onus on npm to fix 50 | Community is already working around this (ex. Angular flattens /w config flag, npm-doctor etc.) 51 | Tierney: 52 | Advocating for explicit command 53 | Next steps: 54 | RFC: check code for unlisted deps in `npm doctor` 55 | RFC: print warnings at runtime for `npm test` under tink (npm >= v8) 56 | 57 | 4. Review/converse on sustainability & support drafts 58 | 59 | Wesley: 60 | package maintenance WG looking at how to better support the maintainer that wants to communicate *support* 61 | `backing` overlap with *sustainability* proposal 62 | Isaac: 63 | Schema itself looks perfect 64 | Problems with number of changes that object may see 65 | Next steps: 66 | npm to provide feedback on existing issues/drafted spec 67 | Draft an RFC on npm/rfcs once there is consensus from Package Maintenance WG 68 | -------------------------------------------------------------------------------- /meetings/2020-03-25.md: -------------------------------------------------------------------------------- 1 | #### Wednesday March 25th 2020 2 | # Open RFC Deep Dive 3 | 4 | ### Attendees 5 | - Darcy Clarke (@darcyclarke) 6 | - Dominykas Blyžė (@dominykas) 7 | - Ruy Adorno (@ruyadorno) 8 | - Claudia Hernández (@claudiahdz) 9 | - Wes Todd (@wesleytodd) 10 | - Jordan Harband (@LJHarb) 11 | - Michael Dawson (@mhdawson1) 12 | - Isaac Z. Schlueter (@isaacs) 13 | - Emelia Smith (@thisismissem) 14 | 15 | ### Agenda 16 | 1. **Housekeeping** 17 | 1. Introduction(s) 18 | 1. Code of Conduct Acknowledgement 19 | 1. Outline Intentions & Desired Outcomes 20 | 1. Announcements 21 | 1. **PR**: [#92 RFC: Add staging workflow for CI and human interoperability](https://github.com/npm/rfcs/pull/92) 22 | 1. Scope (initial support) 23 | 1. Usecases 24 | 1. Implementation details 25 | 26 | ### Notes 27 | - There are a handful of different use cases, hence the need for a deep dive 28 | - Need for publishing from CI and having an extra step where a person can promote the publish to production 29 | - authentication/authorization should live server-side 30 | - How to push out to beta? pre-release semver tags vs staged publishes 31 | - Sharing inside my team vs outside my team 32 | - Currently implemented in `npm-pick-manifest`: deprioritize staged versions 33 | - There's a difference between using pre-release tags that are accesible to the public and a private staging environment that allows for testing and sharing with a limited amount of people 34 | - Draft private publish (ex. wordpress/tumblr/medium draft) only installable by the publishers, only installable by people who the publish was shared with 35 | - ability to install staged versions of specific deps that will make that dep and all it's deps pull the staged versions, instead of a single `staged` flag that applies to the whole tree 36 | ex `npm i -staged=tap@next, nyc@next` 37 | ex `npm install tap@15 --include-staged=tap` 38 | - should explicitly opt-in (should make it difficult to get by accident) 39 | - deleting things: 40 | + should staged versions be deleted automatically if they never get publish/promoted? in what time window? 41 | + when should staged versions be deleted? 42 | + can you have 2 same-numbered staged versions at the same time? 43 | - Should staged versions be added to the package.lock? 44 | + lockfile could include two URLs - the staged one and the non staged alternative 45 | - What if people depend on a package that is never promoted? 46 | - npm should provide a way of warning the user about the usage of staged versions in their install -------------------------------------------------------------------------------- /implemented/0014-devoptional-shrinkwrap-flag.md: -------------------------------------------------------------------------------- 1 | # `devOptional` flag in package-lock.json 2 | 3 | ## Summary 4 | 5 | Add a `devOptional` flag to shrinkwrap/lockfile entries to indicate 6 | packages that are in both the `dev` and `optional` trees, but not in only 7 | one or the other. 8 | 9 | ## Motivation 10 | 11 | Currently, there is no way to easily identify in a shrinkwrap that a 12 | package is a meta-dependency in the overlap of the `dev` and `optional` 13 | subtrees. 14 | 15 | The `dev` flag indicates that the package is a child of the `dev` tree, and 16 | not required by any non-dev dependencies. The `optional` flag indicates 17 | that a package is a child of the `optional` tree, and not required by any 18 | non-optional dependencies. 19 | 20 | If a package is an optional dependency of a dev dependency, then it will 21 | have both flags set. 22 | 23 | However, if a package is a regular dependency of _both_ a dev dependency 24 | _and_ an optional dependency, then neither flag is set. 25 | 26 | This makes it difficult to implement pruning and filtering for both 27 | `--no-optional` and `--production` at the same time. 28 | 29 | ## Detailed Explanation 30 | 31 | Consider this dependency graph: 32 | 33 | ``` 34 | root 35 | +-dev-> b ---+ 36 | | | 37 | | v 38 | +-opt-> c -> d 39 | ``` 40 | 41 | The root package has a dev dependency on `b`, and an optional dependency on 42 | `c`. `b` and `c` both have a dependency on `d`, which is deduplicated. 43 | 44 | If we want to prune all dev and optional dependencies, then `d` should be 45 | pruned. 46 | 47 | However, because `d` is not "onlyDev", the `dev` flag is not set in the 48 | shrinkwrap. And, because it is also not "onlyOptional", the `optional` 49 | flag is not set. 50 | 51 | In this case, a new flag, `devOptional` will be added. 52 | 53 | The `devOptional` set is the packages in both the dev and optional trees, 54 | which are not solely in either tree. 55 | 56 | ## Rationale and Alternatives 57 | 58 | This opens the door for `npm prune --production --no-optional`, without 59 | having to re-walk the tree to find packages that are neither `onlyDev` nor 60 | `onlyOptional`. 61 | 62 | ## Implementation 63 | 64 | Already implemented in `@npmcli/arborist`. Will be included in npm v7. 65 | 66 | Internally, Arborist nodes have the `devOptional` flag if they are either 67 | dev _or_ optional (ie, it is the union of the two sets). But, 68 | `devOptional` is only set in the shrinkwrap if they do not have `dev` or 69 | `optional` set as well. 70 | -------------------------------------------------------------------------------- /accepted/0028-publish-prompt.md: -------------------------------------------------------------------------------- 1 | # Publish confirmation prompt 2 | 3 | ## Summary 4 | 5 | Publishing a package should prompt a confirmation prompt, allowing users to validate their package info and the target registry before uploading their package tarball. 6 | 7 | ## Motivation 8 | 9 | Breaking the prompt into a two-step operation allows for a validation of contents prior to uploading the package. 10 | 11 | ## Detailed Explanation and Rationale 12 | 13 | `npm publish` should ask for a confirmation prompt prior to uploading the package tarball. 14 | 15 | Currently "publish" has a very nice **unintended UX** for users with 2FA enabled, in which it stops the publish process in order to ask for the OTP code, allowing for a review of the file contents (and even cancelling the process altogether) prior to uploading the tarball file. 16 | 17 | A broader population of package authors can benefit from this UX if we formalize it. Allowing for review of contents and cancellation of package publishing. 18 | 19 | ### Feedback from the discussion around this RFC 20 | 21 | - Should be implemented behind an opt-in flag for npm@7 22 | - Non-TTY environments should skip the prompt. 23 | 24 | ## Alternatives 25 | 26 | 1. Not implement it, keep the current behavior. 27 | 28 | ## Implementation 29 | 30 | Prompts the user for confirmation when using the opt-in flag: 31 | 32 | ```sh 33 | $ npm publish --publish-confirmation 34 | 35 | npm notice 36 | npm notice 📦 disparity@3.0.0 37 | npm notice === Tarball Contents === 38 | npm notice 183B bin/disparity 39 | npm notice 2.1kB disparity-cli.js 40 | npm notice 4.3kB disparity.js 41 | npm notice 999B package.json 42 | npm notice 875B CHANGELOG.md 43 | npm notice 1.1kB LICENSE.md 44 | npm notice 3.7kB README.md 45 | npm notice === Tarball Details === 46 | npm notice name: disparity 47 | npm notice version: 3.0.0 48 | npm notice filename: disparity-3.0.0.tgz 49 | npm notice package size: 5.2 kB 50 | npm notice unpacked size: 13.3 kB 51 | npm notice shasum: 4344ee202484ab134227913a3af6f4a0ae5f0a59 52 | npm notice integrity: sha512-NAItmPQyt6dya[...]m5N3kfPPJYj0w== 53 | npm notice total files: 7 54 | npm notice 55 | 56 | This operation will publish your package to the npm registry at https://registry.npmjs.org. 57 | Do you wish to proceed? [y/N] 58 | ``` 59 | 60 | The user can also provide a `--yes` option that can skip the prompt and keep current behavior: 61 | 62 | ``` 63 | $ npm publish --publish-confirmation --yes 64 | ``` 65 | 66 | ## Prior Art 67 | 68 | Currently `npm publish` will automatically publish the tarball to the registry without any confirmation prompt in case the user does not have OTP enabled. 69 | -------------------------------------------------------------------------------- /meetings/2020-06-17.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: June 17th, 2020 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Myles Borins (@MylesBorins) 8 | - Wes Todd (@wesleytodd) 9 | - Jordan Harband (@LJHarb) 10 | - Ruy Adorno (@ruyadorno) 11 | - Claudia Hernández (@claudiahdz) 12 | 13 | ### Agenda 14 | 15 | 1. **Housekeeping** 16 | 1. Introduction(s) 17 | 1. Code of Conduct Acknowledgement 18 | 1. Outline Intentions & Desired Outcomes 19 | 1. Announcements 20 | 1. **PR**: [#150 RFC: Add file+pack dependency protocol](https://github.com/npm/rfcs/pull/150) 21 | 1. **PR**: [#126 RFC: Adding types information to the Package JSON in the registry](https://github.com/npm/rfcs/pull/126) 22 | 1. **PR**: [#129 RFC: overrides](https://github.com 23 | /npm/rfcs/pull/129) 24 | 1. **PR**: [#117 RFC: npm workspaces - Running Commands](https://github.com/npm/rfcs/pull/117) 25 | 1. **PR**: [#18 npm audit resolve](https://github.com/npm/rfcs/pull/18) 26 | 27 | 28 | **Other Action Items**: 29 | - [ ] Create issues for backlogged action items in previous calls 30 | - [ ] Create poll for alternative day/time schedule to accommodate timezones 31 | - [ ] Review existing **accepted** RFCs & provide an update on their status 32 | - [ ] Update issue template & agenda generation script 33 | - [ ] Update public events calendar & meeting information 34 | 35 | ### Notes 36 | - Myles Borins is now Product Manager @Github and will be involved with the npm team! 37 | - Open Collab Summit next week 38 | 39 | ### Add file+pack dependency protocol 40 | - currently it's a pain for users using monorepos to run prepack scripts during the build process for all dependencies 41 | - adding a new protocol might not be the best idea right now considering the current undergoing implementation of workspaces at npm 42 | - pack is not currently on the scope of running subcommands for workspaces 43 | - isaacs seems to be in favor of a protocol and the RFC will probably be discussed again in an upcoming session 44 | ### Adding types information to the Package JSON in the registry 45 | - RFC ready to be ratified 46 | 47 | ### overrides 48 | - specify dependency type not only depedency spec 49 | - override this if its under depedencies 50 | 51 | ### npm workspaces - Running Commands 52 | - current undergoing poll for preference on how to filter workspaces: https://github.com/npm/rfcs/issues/160 53 | - probably going to be mentioned next week in the collab summit 54 | 55 | ### npm audit resolve 56 | - planned to be added as a minor for v7 but may vary depending on implementation 57 | - rfc is tied to the interactive side of it and will probably need to be splitted up, one rfc for functionality and another for the ux feel 58 | 59 | -------------------------------------------------------------------------------- /meetings/2021-09-22.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: September 22nd, 2021 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Nathan Fritz (@fritzy) 8 | - Isaac Z. Schlueter (@isaacs) 9 | - Luke Karrys (@lukekarrys) 10 | - Jordan Harband (@ljharb) 11 | - Owen Buckley (@thescientist13) 12 | 13 | ### Previously... 14 | 15 | - [2021-09-15](https://github.com/npm/rfcs/blob/latest/meetings/2021-09-15.md) 16 | 17 | ### Agenda 18 | 19 | 1. **Housekeeping** 20 | 1. Introduction(s) 21 | 1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct) 22 | 1. Outline Intentions & Desired Outcomes 23 | 1. Announcements 24 | 1. **Issue**: [#445 ⚠️ [RRFC] Breaking changes for `npm@8`](https://github.com/npm/rfcs/issues/445) - @nlf 25 | 1. **PR**: [#434 Support package-lock.json v3 in npm 7](https://github.com/npm/rfcs/pull/434) - @remcohaszing 26 | 1. **PR**: [#422 RFC: audit assertions](https://github.com/npm/rfcs/pull/422) - @bnb 27 | 28 | ### Notes 29 | 30 | #### **Issue**: [#445 ⚠️ [RRFC] Breaking changes for `npm@8`](https://github.com/npm/rfcs/issues/445) - @nlf 31 | - @ljharb should we try to address all concerns users have for upgrading npm@6 -> npm@7 before cutting npm@8? 32 | - @isaacs yes/kind of; depending on the amount of work & blockers 33 | - @ljharb 34 | - seems like the categories of problems are: 35 | - `npm update` & not saving back to `package.json` 36 | - auth against git repositories 37 | - @isaacs 38 | - @ljharb 39 | - we should do a pass again against npm v7 issues for upgrade paths 40 | 41 | #### **PR**: [#434 Support package-lock.json v3 in npm 7](https://github.com/npm/rfcs/pull/434) - @remcohaszing 42 | - **Action:** @isaacs to review & land RFC 43 | 44 | #### **PR**: [#422 RFC: audit assertions](https://github.com/npm/rfcs/pull/422) - @bnb 45 | - @ljharb 46 | - maintainers are unduely burdened without a feature/mechanism for addressing CVEs 47 | - @isaacs 48 | - this is broader then npm itself 49 | - there is a seperate discussion & spec being developed for exemptions 50 | - @ljharb 51 | - current incumbent organizations filing CVEs are incentivised not to change the current situation/tooling 52 | - @isaacs 53 | - not speaking on behalf of GitHub but... 54 | - that organization seems to have similar goals/alignment w/ maintainers 55 | - @darcyclarke 56 | - should we take an approach like @naugter has proposed w/ npm-audit-resolver to specify a local file w/ audit resolutions? 57 | - @isaacs 58 | - so ignoring a metadep vuln sounds preferrable 59 | - if you rely directly on a dep with a vuln though you should still be wanred about it 60 | - **Actions**: 61 | - [ ] Propose a new RFC (pulling in ideas from the old audit resolver PR) for a local file ignore/resolution list for metadeps 62 | -------------------------------------------------------------------------------- /meetings/2020-04-29.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: April 29th, 2020 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Ruy Adorno (@ruyadorno) 8 | - Isaac Z. Schlueter (@isaacs) 9 | - Wes Todd (@wesleytodd) 10 | - Claudia Hernández (@claudiahdz) 11 | - Orta Therox (@orta) 12 | - Jordan Harband (@ljharb) 13 | 14 | ### Agenda 15 | 16 | 1. **Housekeeping** 17 | 1. Introduction(s) 18 | 1. Code of Conduct Acknowledgement 19 | 1. Outline Intentions & Desired Outcomes 20 | 1. Announcements 21 | 1. **PR**: [#117 RFC: npm workspaces - Running Commands](https://github.com/npm/rfcs/pull/117) 22 | 1. **PR**: [#129 RFC: overrides](https://github.com/npm/rfcs/pull/129) 23 | 1. **Issue**: [[RFC] opt out of optional meta-dependency](https://github.com/npm/rfcs/issues/112) 24 | 1. **PR**: [#133 RFC: Remove --depth from npm outdated](https://github.com/npm/rfcs/pull/133) 25 | 1. **PR**: [#121 RFC: Added proposal for package version syntax](https://github.com/npm/rfcs/pull/121) 26 | 1. **PR**: [#126 RFC: Adding types information to the Package JSON in the registry](https://github.com/npm/rfcs/pull/126) 27 | 28 | 29 | ### Notes 30 | - workspaces: standardizing set of npm commands that will be supported with npm workspaces 31 | - Discussion on how to filter a subset of workspaces that is intuitive and nice: 32 | + workspaces/ws should be aliases not different commands 33 | + long and short version of filter parameter 34 | + explicit option names with no positional arguments 35 | ``` 36 | npm ws <workspaceName> <command> 37 | vs. 38 | npm ws <command> <--config> <workspaceName> 39 | ``` 40 | + npm config flags on the cli are also configurable through the .`.npmrc` file 41 | + concerns on the syntax of the command, syntax should be clear enough to express what it does with just reading it 42 | - overrides: only the first match at a given spec will be honored 43 | - opt-out optional deps: legit problem, terrible UX, a user should be able to opt-out of optional deps 44 | - scenario where i dont want optional dependencies to be installed by default 45 | - discussions on what's the best UX for this feature, without having to add new things to the API 46 | - agreed on revisiting it later (maybe npm v8) 47 | - remove `npm outdated --depth`: 48 | * current use case seems to be only `--depth=9999` 49 | * this change would align with how community uses `outdated` & the fact `update` is already removing this 50 | * concerns on adding a new flag that impacts other commands since flags are global 51 | - types: add a single flag that declares that types are included on the package 52 | - type config that declares where the types are and not only if the package includes them 53 | - find a more informative way than a boolean field that we can include on the package.json -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | <!-- This file is automatically added by @npmcli/template-oss. Do not edit. --> 2 | 3 | # Contributing 4 | 5 | ## Code of Conduct 6 | 7 | All interactions in the **npm** organization on GitHub are considered to be covered by our standard [Code of Conduct](https://docs.npmjs.com/policies/conduct). 8 | 9 | ## Reporting Bugs 10 | 11 | Before submitting a new bug report please search for an existing or similar report. 12 | 13 | Use one of our existing issue templates if you believe you've come across a unique problem. 14 | 15 | Duplicate issues, or issues that don't use one of our templates may get closed without a response. 16 | 17 | ## Pull Request Conventions 18 | 19 | ### Commits 20 | 21 | We use [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/). 22 | 23 | When opening a pull request please be sure that either the pull request title, or each commit in the pull request, has one of the following prefixes: 24 | 25 | - `feat`: For when introducing a new feature. The result will be a new semver minor version of the package when it is next published. 26 | - `fix`: For bug fixes. The result will be a new semver patch version of the package when it is next published. 27 | - `docs`: For documentation updates. The result will be a new semver patch version of the package when it is next published. 28 | - `chore`: For changes that do not affect the published module. Often these are changes to tests. The result will be *no* change to the version of the package when it is next published (as the commit does not affect the published version). 29 | 30 | ### Test Coverage 31 | 32 | Pull requests made against this repo will run `npm test` automatically. Please make sure tests pass locally before submitting a PR. 33 | 34 | Every new feature or bug fix should come with a corresponding test or tests that validate the solutions. Testing also reports on code coverage and will fail if code coverage drops. 35 | 36 | ### Linting 37 | 38 | Linting is also done automatically once tests pass. `npm run lintfix` will fix most linting errors automatically. 39 | 40 | Please make sure linting passes before submitting a PR. 41 | 42 | ## What _not_ to contribute? 43 | 44 | ### Dependencies 45 | 46 | It should be noted that our team does not accept third-party dependency updates/PRs. If you submit a PR trying to update our dependencies we will close it with or without a reference to these contribution guidelines. 47 | 48 | ### Tools/Automation 49 | 50 | Our core team is responsible for the maintenance of the tooling/automation in this project and we ask contributors to not make changes to these when contributing (e.g. `.github/*`, `.eslintrc.json`, `.licensee.json`). Most of those files also have a header at the top to remind folks they are automatically generated. Pull requests that alter these will not be accepted. 51 | -------------------------------------------------------------------------------- /meetings/2022-06-01.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: June 1st, 2022 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Gar (@wraithgar) 8 | - Jon Jensen (@jenseng) 9 | - Owen Buckley (@thescientist13) 10 | - Jordan Harband (@ljharb) 11 | - Nathan LaFreniere (@nlf) 12 | - Ruy Adorno (@ruyadorno) 13 | - 14 | - 15 | - 16 | ### Agenda 17 | 18 | 1. **Housekeeping** 19 | 1. Introduction(s) 20 | 1. Code of Conduct Acknowledgement 21 | 1. Outline Intentions & Desired Outcomes 22 | 1. Announcements 23 | - [**v9 Roadmap**](https://github.com/npm/statusboard/issues/443) (Check it out) 24 | - OpenJS World - https://openjsf.org/openjs-world-2021/ 25 | 1. **PR**: [#595 Propose backwards-compatible improvements to compression](https://github.com/npm/rfcs/pull/595) - @EvanHahn 26 | 1. **PR**: [#593 Only Registry Tarballs](https://github.com/npm/rfcs/pull/593) - @thescientist13 27 | 1. **PR**: [#591 RFC: Registry-scoped keyfile / certfile credential options](https://github.com/npm/rfcs/pull/591) - @jenseng 28 | 1. **PR**: [#564 RFC: Dependency Selector Syntax & `npm query`](https://github.com/npm/rfcs/pull/564) - @darcyclarke 29 | 30 | ### Notes 31 | 32 | #### **PR**: [#595 Propose backwards-compatible improvements to compression](https://github.com/npm/rfcs/pull/595) - @EvanHahn 33 | - Sounds like a good idea but we would need a JavaScript implementation (similar to how we have `tar` today) in order to impleement it 34 | - Overall sentiment is that the compression improvement is welcome but it looks like it would take a proof of concept and challenge some of the edge cases to see if there are any unintended consequences, etc 35 | 36 | #### **PR**: [#593 Only Registry Tarballs](https://github.com/npm/rfcs/pull/593) - @thescientist13 37 | - Needs more clarification: 38 | - add the flag to `npm audit` instead of `npm install` ? 39 | - as long as the lock file is available `npm audit` will work as expected. 40 | - `npm install` should have a flag to respect the status of `npm audit` 41 | - `eslint`-like config needs to exist for `npm audit` 42 | - these configs could/would have three different values (ex. off/warn/fail) 43 | - current set of audit checks can/would include: 44 | - peer deps 45 | - engines 46 | - vulnerabilities 47 | - signatures 48 | - dependency-types 49 | - licenses 50 | - **Actions:** 51 | - [ ] @thescientist13 to update RFC based on feedback 52 | 53 | #### **PR**: [#591 RFC: Registry-scoped keyfile / certfile credential options](https://github.com/npm/rfcs/pull/591) - @jenseng 54 | - @wraithgar 55 | - this was an oversight 56 | - should have always worked this way 57 | 58 | #### **PR**: [#564 RFC: Dependency Selector Syntax & `npm query`](https://github.com/npm/rfcs/pull/564) - @darcyclarke 59 | - @ruyadorno 60 | - still a WIP 61 | - will have more to show next week 62 | -------------------------------------------------------------------------------- /meetings/2020-04-22.md: -------------------------------------------------------------------------------- 1 | 2 | #### Wednesday, April 22, 2020, 2:00 PM EST 3 | # Open RFC Meeting - Deep Dive 4 | 5 | ### Attendees 6 | 7 | - Darcy Clarke (@darcyclarke) 8 | - Wes Todd (@wesleytodd) 9 | - Claudia Hernández (@claudiahdz) 10 | - Ruy Adorno (@ruyadorno) 11 | - Isaac Z. Schlueter (@isaacs) 12 | - Jordan Harband (@ljharb) 13 | 14 | ### Agenda 15 | 16 | 1. **Housekeeping** 17 | 1. Introduction(s) 18 | 1. Code of Conduct Acknowledgement 19 | 1. Outline Intentions & Desired Outcomes 20 | 1. Announcements 21 | 1. Topic: 22 | * **Resolutions/Overrides** 23 | 1. References: 24 | * [**Legacy** Overrides RFC](https://github.com/npm/rfcs/blob/latest/accepted/0009-package-overrides.md) 25 | * [**New** Overrides RFC](https://github.com/npm/rfcs/pull/129) 26 | * [Previous: **Overrides Deep Dive - Agenda**](https://github.com/npm/rfcs/issues/124) 27 | * [Previous: **Overrides Deep Dive - Video Recording**](https://www.youtube.com/watch?v=GTocZoiiu4k&feature=youtu.be) 28 | * [Previous: **Overrides Deep Dive - Notes**](https://github.com/npm/rfcs/blob/latest/meetings/2020-04-08.md) 29 | 30 | 31 | ### Notes: 32 | - Discussions on implementation: 33 | Find one override and we're done: once there's a match we will not apply any other overrides, whether is string or object values 34 | - String and object values like: 35 | 36 | ```json 37 | { 38 | "typescript@^3.8": "3.7", 39 | "react": "15", 40 | "react@15": { 41 | "loose-envify@1": "1.3.1" 42 | }, 43 | "tap": { 44 | "react": "16.13.1" 45 | } 46 | } 47 | ``` 48 | 49 | Reference: https://github.com/npm/rfcs/blob/isaacs/overrides/accepted/0000-overrides.md#object-overrides
 50 | 51 | - Isaac: We have to treat string and object overrides differently, this affects how we merge and deduplicate packages 52 | - Overrides field string structure on `package.json`: 53 | **left hand value**: a name package specifier, github repo link with at a particular branch/commit 54 | **right hand value**: an unnamed package specifier that uses alias specifiers 55 | - Examples: 56 | ``` 57 | "foo": "npm:@fancy/foo@${VERSION}" 58 | "foo": "npm:@fancy/foo" 59 | "foo": "https://my-registry/foo/-/foo-${VERSION}.tgz" 60 | “foo”: “latest” 61 | ``` 62 | - If you match the left hand value it gets overriden by the right side 63 | - Challanges: figure out which overrides are relevant at a given point of time in the code 64 | - Good aligntment of what should be included in v1 65 | - - Wes talks about company/team wide package restrictions 66 | - shouldn't take the config out of the thing it is trying to config 67 | - npm has no concept of team-level configs 68 | - v1: npm install and then re-install to get overrides? We assume we get overrides from somewhere 69 | - Jordan: overrides on the packument? 70 | - Isaac to update the RFC with ideas discussed (version defaults, capture groups, sharing configs etc) 71 | 72 | 73 | 74 | 75 | 76 | 77 | -------------------------------------------------------------------------------- /.github/workflows/ci.yml: -------------------------------------------------------------------------------- 1 | # This file is automatically added by @npmcli/template-oss. Do not edit. 2 | 3 | name: CI 4 | 5 | on: 6 | workflow_dispatch: 7 | pull_request: 8 | push: 9 | branches: 10 | - main 11 | schedule: 12 | # "At 09:00 UTC (02:00 PT) on Monday" https://crontab.guru/#0_9_*_*_1 13 | - cron: "0 9 * * 1" 14 | 15 | permissions: 16 | contents: read 17 | 18 | jobs: 19 | lint: 20 | name: Lint 21 | if: github.repository_owner == 'npm' 22 | runs-on: ubuntu-latest 23 | defaults: 24 | run: 25 | shell: bash 26 | steps: 27 | - name: Checkout 28 | uses: actions/checkout@v4 29 | - name: Setup Git User 30 | run: | 31 | git config --global user.email "npm-cli+bot@github.com" 32 | git config --global user.name "npm CLI robot" 33 | - name: Setup Node 34 | uses: actions/setup-node@v4 35 | id: node 36 | with: 37 | node-version: 22.x 38 | check-latest: contains('22.x', '.x') 39 | - name: Install Latest npm 40 | uses: ./.github/actions/install-latest-npm 41 | with: 42 | node: ${{ steps.node.outputs.node-version }} 43 | - name: Install Dependencies 44 | run: npm i --ignore-scripts --no-audit --no-fund 45 | - name: Lint 46 | run: npm run lint --ignore-scripts 47 | - name: Post Lint 48 | run: npm run postlint --ignore-scripts 49 | 50 | test: 51 | name: Test - ${{ matrix.platform.name }} - ${{ matrix.node-version }} 52 | if: github.repository_owner == 'npm' 53 | strategy: 54 | fail-fast: false 55 | matrix: 56 | platform: 57 | - name: Linux 58 | os: ubuntu-latest 59 | shell: bash 60 | node-version: 61 | - 18.0.0 62 | - 18.x 63 | - 20.x 64 | - 22.x 65 | runs-on: ${{ matrix.platform.os }} 66 | defaults: 67 | run: 68 | shell: ${{ matrix.platform.shell }} 69 | steps: 70 | - name: Checkout 71 | uses: actions/checkout@v4 72 | - name: Setup Git User 73 | run: | 74 | git config --global user.email "npm-cli+bot@github.com" 75 | git config --global user.name "npm CLI robot" 76 | - name: Setup Node 77 | uses: actions/setup-node@v4 78 | id: node 79 | with: 80 | node-version: ${{ matrix.node-version }} 81 | check-latest: contains(matrix.node-version, '.x') 82 | - name: Install Latest npm 83 | uses: ./.github/actions/install-latest-npm 84 | with: 85 | node: ${{ steps.node.outputs.node-version }} 86 | - name: Install Dependencies 87 | run: npm i --ignore-scripts --no-audit --no-fund 88 | - name: Add Problem Matcher 89 | run: echo "::add-matcher::.github/matchers/tap.json" 90 | - name: Test 91 | run: npm test --ignore-scripts 92 | -------------------------------------------------------------------------------- /meetings/2019-12-13.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: December 13th, 2019 2 | # Open RFC Meeting (npm) 3 | 4 | ### Attendees: 5 | 6 | - Darcy Clarke (@darcyclarke) (Twitter: @darcy) 7 | - Stephen Belanger (qard) 8 | - Lucas Holmquist(@lholmquist) 9 | - Eemeli Aro (@eemeli) 10 | - Tobias Nießen (@tniessen) 11 | - Jason Miller (@developit) 12 | - Michael Perrotte (@mikemimik) 13 | - Ahmad Nassri (@ahmadnassri) 14 | - Erick Wendel (@erickwendel | @erickwendel_) 15 | - Wes Todd (@wesleytodd) 16 | - Matan Kushner (@matchai) 17 | - Geoff Goodman (@ggoodman) 18 | - Jory Burson (@jorydotcom) 19 | - Ethan Arrowood (@ethan-arrowood) 20 | - Michael Dawson (@mhdawson) 21 | - Em Lazer-Walker (@lazerwalker) 22 | - Jessica Janiuk (@janiukjf) 23 | - Rachel Romoff (@rromoff) 24 | - Glenn Hinks (@ghinks) 25 | - Gireesh Punathil (@gireeshpunathil) 26 | - Anna Henningsen (@addaleax) 27 | - Sakhi Mansoor(@sakhisheikh) 28 | - Ryan Day (@soldair) 29 | - Geoffrey Booth (@GeoffreyBooth) 30 | - Robin Ginn (@rginn) 31 | - Ruy Adorno (@ruyadorno) 32 | - Alex Bushnev (@alex_bushnev) 33 | - Akshay Sawant (@IamAkshaySawant) 34 | - Jim Schlight (@jschlight) 35 | - James M Snell (@jasnell) 36 | - Matteo Collina (@matteocollina) 37 | - Jason Etcovitch (@JasonEtco) 38 | - Trivikram Kamat (@trivikr) 39 | - Nicola Del Gobbo (@NickNaso) 40 | - Alejandro Oviedo (@a0viedo) 41 | - Marcos Frony (@mfrony) 42 | - Hugo Ortiz (@hortizr) 43 | - Jose L Bucio (@jbucio2) 44 | - Owen Buckley (@thescientist13) 45 | 46 | ### Agenda: 47 | 48 | - Housekeeping (introductions, outlining intentions & desired outcomes) 49 | - Theft of meeting patterns 😂 50 | - Overview of Why/What/How 51 | - https://github.com/npm/rfcs 52 | - Template, process etc documentation 53 | - https://www.youtube.com/channel/UCK71Wk0I45SLTSXQA23GdIw 54 | - Open RFCs meetings playlist https://www.youtube.com/playlist?list=PLQso55XhxkgBKhtFahRx20wyWE488kKJJ 55 | - npm.community 56 | - https://github.com/npm/statusboard - must have zenhub ext to see the board stuff 57 | - Link to the slides: bit.ly/beyond-install 58 | - Helpful community tools 59 | - https://github.com/npm/open-source-project-boilerplate 60 | - https://github.com/pkgjs (basis of status board for npm & express) 61 | - npm project statusboard https://npm.github.io/statusboard/ 62 | - Crowd Source Topics/Questions; Retro(?) 63 | 64 | ### Notes: 65 | 66 | - Idea for npm process: make goals/priorities more clear for the community vis-a-vis what will be likely to be updated/addressed etc. “If I submit this RFC, what’s likely to happen to it? Should I open the issue at all?” 67 | - Eg: being clear that support for A is out of scope; X new feature is something we are prioritizing; Y new feature would be a welcome contribution, etc 68 | - You don’t need to write a “full RFC” to contribute, you can start a discussion / question in the issues 69 | - Question: What is most helpful to the npm team right now wrt the rfc process? What do you need? Help on outstanding issues, new rfcs, ?? 70 | -------------------------------------------------------------------------------- /meetings/2019-10-02.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: October 2nd, 2019 2 | # Open RFC Meeting (npm) 3 | 4 | ### Attendees: 5 | 6 | - Darcy Clarke (@darcyclarke) 7 | - Ruy Adorno (@ruyadorno) 8 | - Claudia Hernández (@claudiahdz) 9 | - Daniel Sauble (@djsauble) 10 | - Wes Todd (@wesleytodd) 11 | 12 | ### Agenda: 13 | 14 | - Housekeeping (introductions, outlining intentions & desired outcomes) 15 | - Discuss proposals & ideas on the PRs/issues outlined 16 | - Open PRs, Templates & labels 17 | - npm support subcommand 18 | - npm cache list 19 | - docs: scoped names can begin with '.' & '_' 20 | - #48 Link .hook scripts 21 | - #1 Display package size information postinstall 22 | - #51 Expose arborist metadata to lifecycle scripts 23 | - #43 Peer dependencies installation 24 | - Document the discussion & next steps 25 | 26 | ### Notes: 27 | - Darcy: Create public calendar with recurring event 28 | - Darcy: Create livestream integration for these calls 29 | - Agenda overview 30 | - Standardizing labels 31 | - Good first issue 32 | - Needs discussion (?) 33 | - Try to set common standards across the communities 34 | - Support subcommand 35 | - Schema conversation in the package maintenance group 36 | - PR open in the cli: https://github.com/npm/cli/pull/246 37 | - Support from other cli clients 38 | - Intention to land asap in the npm cli 39 | - Possible confusion with the name “Support” from users (is this related to the npm Inc. support team?) 40 | - Concerns about the schema consensus, it’s going to be hard to change it after landing an initial implementation 41 | - Package maintenance team is more concerned about a long term solution 42 | - Loop back with the package maintenance working group 43 | - Segment the conversation 44 | - Then the current PR can tackle only that specific part (monetary) of the problem that the working group is currently tackling 45 | - npm cache list 46 | - Ping Isaacs about it in order to get feedback 47 | - labeled as semver-minor so it can potentially be a part of next release 48 | - PR open in the cli: https://github.com/npm/cli/pull/194 49 | - Docs: scoped names can begin with '.' & '_' 50 | - Seems to be wip 51 | - Open PR: https://github.com/npm/cli/pull/134 52 | - Link .hook scripts 53 | - Seems to have a concern from Isaacs 54 | - Open PR: https://github.com/npm/rfcs/pull/48 55 | - Display package info post-install 56 | - Open PR: https://github.com/npm/rfcs/pull/1 57 | - Concerns about it being a misleading metric for end users 58 | - Hide it behind a flag or create a separate command (?) 59 | - Expose arborist metadata to lifecycle scripts 60 | - Need input from Isaacs 61 | - Open PR: https://github.com/npm/rfcs/pull/51 62 | - Peer dependencies installation 63 | - Maybe have a session with the rest of the team to explain to the team the background history here and why do we want to do it again 64 | - Meta: make sure we have a livestream next time in order to help increase awareness of the open rfc calls 65 | -------------------------------------------------------------------------------- /implemented/0032-powershell-bins.md: -------------------------------------------------------------------------------- 1 | # Powershell for Installed Binaries 2 | 3 | AKA Terminate Terminate Batch Job 4 | 5 | ## Implemented 6 | 7 | Landed on [cmd-shim](https://github.com/npm/cmd-shim/pull/34) in v2.1.0, 8 | and in [npm/cli 6.11.0](https://github.com/npm/cli/releases/tag/v6.11.0). 9 | 10 | ## Summary 11 | 12 | Today, installing binaries using npm creates an executable bash script and a .cmd file with the same name. Unfortunately, terminating cmd scripts with SIGINT causes a useless prompt for windows users - "Terminate batch job (Y/N)". Also, Powershell is the default shell for Windows. By creating .ps1 scripts in addition to bash and .cmd, powershell users will have a better command line experience. 13 | 14 | ## Motivation 15 | 16 | Windows users have three main options when it comes to shells: 17 | 18 | - cmd: essentially unchanged from early versions of Windows 19 | - powershell: the default Windows shell, under active development 20 | - unixy shell: for example git-bash, zsh via WSL 21 | 22 | WSL is growing in popularity, but isn't super common. Many Windows users need to use or prefer using a native shell. And for those using Powershell, we can make their experience better by creating powershell binary wrappers. 23 | 24 | ## Detailed Explanation 25 | 26 | When installing binaries (e.g. `npm install -g typescript`), NPM should create `tsc.ps1` in addition to `tsc.cmd` and the executable `tsc` bash script. Powershell will prioritize `foo.ps1` over `foo.cmd` when users type `foo` on the command line. cmd users will have to continue living with it. Users of git-bash or WSL shells will be unaffected. 27 | 28 | ## Rationale and Alternatives 29 | 30 | The main alternative is to maintain the status quo, but this leaves an annoying SIGINT prompt in Windows's default shell. 31 | 32 | Creating just .ps1 scripts isn't an option. cmd can't start treating .ps1 scripts as executables (at least not by default), and NPM can't drop support for cmd. 33 | 34 | ## Implementation 35 | 36 | Here's an example of a functionally identical powershell wrapper: 37 | 38 | ```powershell 39 | $myPath = Split-Path $myInvocation.MyCommand.Path -Parent 40 | $node = Join-Path $myPath 'node.exe' 41 | $binPath = Join-Path $myPath '[ path to node_module bin script, e.g. node_modules\typescript\bin\tsc]' 42 | if (Test-Path $node) 43 | { 44 | & $node $binPath $args 45 | } 46 | else 47 | { 48 | node $binPath $args 49 | } 50 | ``` 51 | 52 | The path to the bin script will have to be substituted into the right place. 53 | 54 | ## Prior Art 55 | 56 | - [cmd-shim](https://www.npmjs.com/package/cmd-shim) 57 | - [yarn PR](https://github.com/yarnpkg/yarn/pull/6093) 58 | 59 | ## Unresolved Questions and Bikeshedding 60 | 61 | - impact of additional scripts on install times, node_modules size, etc. 62 | - default powershell permissions: will powershell users need to toggle some settings so this works without permissions errors? Can the errors be worked around? (This PR will need testing on a fresh Windows install) 63 | -------------------------------------------------------------------------------- /withdrawn/0002-changelog.md: -------------------------------------------------------------------------------- 1 | # Withdrawal Amendment 2 | 3 | - Managing changelog is considered outside of the scope of the **npm cli** 4 | - Recently **npm-packlist** no longer force-includes changelog files by default, ref: https://github.com/npm/npm-packlist/commit/2b29fc274bb5096b337d649f1871f7cfee4f9449 5 | - Long inactive approved RFC 6 | - Current **npm cli** team is unlikely to implement this 7 | 8 | ## Relevant Resources 9 | 10 | Withdrawn consensus achieved during the [Wednesday, June 16, 2021 OpenRFC meeting](https://github.com/npm/rfcs/issues/399) 11 | - Meeting Notes: https://github.com/npm/rfcs/blob/515b8f310eb4605022c8b25849dfc9941f321885/meetings/2021-06-16.md 12 | - Video Recording: https://youtu.be/N6cEmHKPRfo 13 | 14 | # Changelog 15 | 16 | ## Summary 17 | 18 | This RFC introduces the `changelog` command to `npm`. 19 | 20 | ## Motivation 21 | 22 | A changelog file helps keep users of a library up to date on recent changes to 23 | that library. This allows them to better prepare for any bugs that might 24 | surface in their application from these changes. 25 | 26 | Since npm already supports including a changelog with the package by reserving 27 | three possible document names: `CHANGES`, `CHANGELOG`, and `HISTORY` 28 | (with any file extension), this means that we can utilize the included file to 29 | better show what has happened with recent changes to a package. 30 | 31 | This is good for security and general maintenance. 32 | 33 | ## Detailed Explanation 34 | 35 | When a changelog is requested (via `npm changelog`), a user can be taken to the 36 | npm package page for that specific package version - and to the changelog 37 | section for said package. 38 | 39 | ## Rationale and Alternatives 40 | 41 | - https://github.com/dantman/npm-rfcs/blob/changelog/accepted/0000-changelog.md 42 | - Another option is rendering the changelog out at the CLI level, but this 43 | seems much more complicated to nail cross-platform. 44 | 45 | ## Implementation 46 | 47 | - From the registry side, we have pkg-index-lambda, which currently is used in 48 | the same manner for README files. We can expand this to also seek out the files 49 | involved here. We'll then need to go through every package and run this against 50 | it. We'll want to have a discussion about storage costs as well, as this will 51 | put everything into s3 and cache it at the CDN. 52 | 53 | - On the web side, we'll need to add this to the package page - this will 54 | involve design figuring out where it best fits + adding the route to the app. 55 | 56 | ## Prior Art 57 | 58 | See: https://github.com/dantman/npm-rfcs/blob/changelog/accepted/0000-changelog.md for the original idea 59 | 60 | As mentioned, this will work similarly to the README. We should even have a tab on the website. 61 | 62 | ## Unresolved Questions and Bikeshedding 63 | 64 | Any file extension works with `CHANGES` / `CHANGELOG` / `HISTORY`, but npm's 65 | rendering of package files to the website currently only supports markdown. Do 66 | we open this up or convince people to convert to markdown as well? 67 | -------------------------------------------------------------------------------- /implemented/0039-npm-pkg.md: -------------------------------------------------------------------------------- 1 | # npm pkg 2 | 3 | ## Summary 4 | 5 | A new top-level command that manages any property in your `package.json`. 6 | 7 | ## Motivation 8 | 9 | Some users prefer managing their `package.json` using **npm cli** comands rather than manually editing a JSON file. 10 | 11 | As of today, some of the **npm cli** commands already handle the automated management of the `package.json` file, such as `npm install` adding / updating dependency declarations, `npm version` bumping the version value, or in the case of `npm set-script` a top-level command that serves specifically the purpose of managing `"scripts"` data in the `package.json` file. 12 | 13 | ## Detailed Explanation 14 | 15 | - Add a `npm pkg` command that has the following subcommands: 16 | - `npm pkg get <value>` 17 | - `npm pkg set <key>=<value>` 18 | - `npm pkg delete <key>` 19 | 20 | ## Rationale 21 | 22 | Making manage your `package.json` file something less manually curated and more of an automated experience. 23 | 24 | ## Implementation 25 | 26 | - Add a new `lib/pkg.js` top-level command that will handle adding / removing / modifying properties in your `package.json` file. 27 | - Reuses the same logic existing to query for object properties from `lib/view.js` 28 | - Throws when trying to replace current literal values with object notations 29 | - Type cast via json parse using the `--json` cli option 30 | 31 | ### Example 32 | 33 | ``` 34 | $ npm pkg set scripts.lint=eslint 35 | $ npm pkg get scripts 36 | { 37 | "lint": "eslint" 38 | } 39 | $ npm pkg get scripts.lint 40 | "eslint" 41 | $ npm pkg set scripts.lint.eslint.foo=bar 42 | error: "scripts.lint" exists and is not an object 43 | $ npm pkg set scripts.lint.eslint.foo=bar --force 44 | $ npm pkg delete scripts 45 | $ npm pkg set scripts.lint.eslint.foo=bar 46 | $ npm pkg get scripts 47 | { 48 | "lint": { 49 | "eslint": { 50 | "foo": "bar" 51 | } 52 | } 53 | } 54 | $ npm pkg set tap.timeout=60 --json 55 | $ npm pkg get tap 56 | { 57 | "timeout": 60 58 | } 59 | $ npm pkg set contributors[0].name=Ruy contributors[0].email=foo@bar.ca 60 | $ npm pkg set contributors[1].name=Gar contributors[1].email=foo@bar.ca 61 | $ npm pkg get contributors.name 62 | { 63 | "contributors[0].name": "Ruy", 64 | "contributors[1].name": "Gar" 65 | } 66 | $ npm pkg set foo.bar[0][0][0]baz.lorem[ipsum.dolor]sit=amet 67 | $ npm pkg get foo 68 | { 69 | bar: [ 70 | [ 71 | [ 72 | { 73 | baz: { 74 | lorem: { 75 | "ispum.dolor": { 76 | sit: "amet" 77 | } 78 | } 79 | } 80 | } 81 | ] 82 | ] 83 | ] 84 | } 85 | ``` 86 | 87 | ## Prior Art 88 | 89 | ### Other npm cli top-level commands 90 | 91 | - `npm set-script` top-level command that allow users to add new scripts to their package.json 92 | - `npm init -w <ws-path>` init command will add the current path to `"workspaces"` property 93 | - `npm install|uninstall <pkg>` will add/remove deps to `"dependencies"` 94 | 95 | ### Userland alternatives 96 | 97 | - https://www.npmjs.com/package/pkg-jq 98 | -------------------------------------------------------------------------------- /meetings/2021-01-06.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: January 6th, 2021 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Isaac Z. Schlueter (@isaacs) 8 | - Christian Siebmanns (@christian24) 9 | - Nathan LaFreniere (@nlf) 10 | - Michael Garvin (@wraithgar) 11 | - Jordan Harband (@ljharb) 12 | - Wes Todd (@wesleytodd) 13 | 14 | ### Agenda 15 | 1. **Housekeeping** 16 | 1. Introduction(s) 17 | 1. Code of Conduct Acknowledgement 18 | 1. Outline Intentions & Desired Outcomes 19 | 1. Announcements 20 | 1. **Issue**: [#301 [RRFC] Workspaces: support to version specifiers other than semver ranges](https://github.com/npm/rfcs/issues/301) - @ruyadorno 21 | 1. **PR**: [Adding `foregroundScripts` option to `Arborist`](https://github.com/npm/arborist/pull/198) - @isaacs 22 | 23 | ### Notes 24 | 25 | #### **Issue**: [#301 [RRFC] Workspaces: support to version specifiers other than semver ranges](https://github.com/npm/rfcs/issues/301) - @ruyadorno 26 | - @ruyadorno workspaces only supports semver but could & should be able to support things like a git specifier 27 | - @jsg2021 context is pseudo-mono repo 28 | - @ljharb what happens with a workspace semver range today? 29 | - @isaacs workspaces work like linked deps 30 | - @ljharb belive that workspaces & hoisting models are sort of broken by default (end goal should be defining shared vs. not-shared dependencies) 31 | - @ljharb should do a deep-dive without any prior art 32 | - @wesleytodd this is similar to work done, & the prior art, with import maps & the current strategy has many issues/edge cases that we need to continue to support/deal with 33 | - @isaacs can we create a set of fixtures/tests that define all the use/edge cases & build to that spec 34 | - @isaacs sounds like this would be a separate RFC to what this is 35 | - @ruyadorno considering what it would look like to symlink everything in place; It's not too late to change how this works 36 | - @isaacs two issues we're speaking to seem to be: whether a git repo can be a valid workspace & a more fundamental issue around how we resolve dependency trees 37 | - @isaacs will take away the action to write an RFC for the smaller problem 38 | 39 | #### **PR**: [Adding `foregroundScripts` option to `Arborist`](https://github.com/npm/arborist/pull/198) - @isaacs 40 | - @isaacs this brings the old behaivour of npm v6 back/configurable where you do/don't have visible output from scripts 41 | - @ljharb should there be some kind of output even when background scripts are running? 42 | - @isaacs we do log it currently but just under a loglevel 43 | - @ljharb moreso, it would be nice to collapse the output into a single line &/or notify the end-user when any scripts are being run (potentially with status) 44 | - @wesleytodd have seen security issues get caught because of indicators coming from run scripts logging 45 | - @isaacs don't want to flood output/logs but potentially could introduce better logging/messaging in a debug log/file 46 | - @isaacs going to land this as-is for now, potential for improvements on the logging/indicators at the CLI level in the future 47 | -------------------------------------------------------------------------------- /meetings/2020-03-11.md: -------------------------------------------------------------------------------- 1 | #### Wednesday March 10th 2020 2 | # Open RFC Notes 3 | 4 | ### Attendees: 5 | 6 | - Ruy Adorno (@ruyadorno) 7 | - Darcy Clarke (@darcyclarke) 8 | - Jordan Harband (@LJHarb) 9 | - Isaac Z. Schlueter (@isaacs) 10 | - Claudia Hernandez (@claudiahdz) 11 | - Daniel Stockman (@evocateur) 12 | 13 | ### Agenda: 14 | - Housekeeping 15 | - Introduction(s) 16 | - [Code of Conduct](https://www.npmjs.com/policies/conduct) Acknowledgement 17 | - Outline Intentions & Desired Outcomes 18 | - [PR: #103 RFC: Add npm workspaces](https://github.com/npm/rfcs/pull/103) 19 | - Scope (initial support and subsequent workspace-aware commands) 20 | - Usecases (monorepos, multiple package management, etc) 21 | - Install 22 | - Subcommands 23 | - Read configs 24 | 25 | ### Notes: 26 | - RFC focuses on 3 main aspects: 27 | 1. Reading config for workspaces out of package.json 28 | (following lead of current support, ex. yarn) 29 | 2. Ability of CLI to install things properly 30 | 3. Definition of subset of CLI subcommands involved in workspaces 31 | - The simplest first step towards workspaces using arborist would be hoisting everything to the top 32 | - Monorepo approach vs multiple packages in different locations 33 | - The latter adds additional work to the initial implementation 34 | - Compromise to document unsupported use cases/possible workflows for workspaces even if we don't intend to implement them on v1 35 | - Agreement to properly define vocabulary around the feature: how do you define a workspace? a monorepo? etc 36 | - Monorepo does not imply a particular source control system. It means I expect always checking out/track all these packages in one flow (ex. tap/istambul deps, istambul having all its deps on a single git repo) 37 | - `package-lock.json` for every nested package on v2. Right now, everything is a single tree for Arborist and there's only one `package-lock.json` 38 | - Discussion again on: is workspace an isolated unit? a leaf package? a multi-package repository? monorepo vs multirepo 39 | - Discussion on redefinition of terms: 40 | ``` 41 | workspace: 42 | (1) a child package work on it in isolation? 43 | (2) this is the babel workspace and this is the pieces that should work with babel? 44 | ``` 45 | - Everyone fine with npm coming up with new terms that describe better the feature 46 | - How do we unpublish workspaces? 47 | - RFC needs a few edits to focus only on `v1` before ratifying 48 | 49 | 50 | #### Workspaces v1 51 | Expectations: 52 | - monorepo-centric: multiple packages that each have a package.json and are intended to work alltogether 53 | - actions are going to be done from the root of the package 54 | - no dehoisting will happen yet 55 | 56 | #### Workspaces v2 57 | - arborist needs to know that a node is a child package of a workspace and should not be hoisted 58 | 59 | ### References: 60 | - v1 npm Workspaces (WIP): https://github.com/npm/arborist/pull/50 61 | - Changeset's Dictionary: https://github.com/atlassian/changesets/blob/master/docs/dictionary.md 62 | - PNPM's Workspaces: https://pnpm.js.org/en/workspaces 63 | - Bolt's Diagrams of Projects: https://github.com/boltpkg/bolt#bolt 64 | -------------------------------------------------------------------------------- /meetings/2022-02-16.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: February 16th, 2022 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Nathan Fritz (@fritzy) 8 | - Ruy Adorno (@ruyadorno) 9 | - Jordan Harband (@ljharb) 10 | - Owen Buckley (@thescientist13) 11 | 12 | ### Previously... 13 | 14 | - [2022-02-09](https://github.com/npm/rfcs/blob/main/meetings/2022-02-09.md) 15 | 16 | ### Agenda 17 | 18 | 1. **Housekeeping** 19 | 1. Introduction(s) 20 | 1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct) 21 | 1. Outline Intentions & Desired Outcomes 22 | 1. Announcements 23 | - OpenJS World 2022 24 | - https://events.linuxfoundation.org/openjs-world/ 25 | - CFP: https://events.linuxfoundation.org/openjs-world/program/cfp/ 26 | - https://2021.stateofjs.com 27 | 2. **PR**: [#525 Stop storing `integrity` for git dependencies](https://github.com/npm/rfcs/pull/525) - @nlf 28 | - @ruyadorno 29 | - what if we steered users away from git dependencies in general? 30 | - maybe we throw warnings 31 | - maybe we start notifying we're deprecating 32 | - definitely on board with this idea 33 | - @ljharb 34 | - git deps should only be for development 35 | - how do file dependencies behave? we should mimic that experience 36 | - @fritzy 37 | - we should warn when we see transitive dependencies that are gi deps 38 | - @ljharb 39 | - maintainers would have to fork & publish 40 | - deprecation indicates discouragement 41 | - not sure this is a good thing in anyway 42 | - @ruyadorno 43 | - we could do this under a config value to skip git dependencies (ex. `--ignore-git-deps`) 44 | - @ljharb 45 | - Node has a Policies feature 46 | - npm could/should probably support this 47 | - Package authors' declared policies / capabilities 48 | 4. **PR**: [#522 Option for npm diff to ignore cr at eol](https://github.com/npm/rfcs/pull/522) - @oBusk 49 | - @ruyadorno 50 | - we should do whatever `git diff` does/supports 51 | - lets follow the naming of the `git` flag 52 | - keep open for another week & then ratify 53 | 5. **PR**: [#4260 feat(arborist)(reify): add an ability to add a hook](https://github.com/npm/cli/pull/4260) - @fritzy 54 | - @fritzy 55 | - clarify they are not the author 56 | - should be careful about what hooks we add as features 57 | - WIP RFC 58 | 6. **PR**: [#519 RFC: Package Distributions](https://github.com/npm/rfcs/pull/519) - @darcyclarke 59 | - @darcyclarke 60 | - no updates yet but seeing a lot of traction in the community 61 | - @ruyadorno 62 | - are we going to open a diff PR for the "Expanding optional dependencies conditions"? 63 | - this would mean it's easier/faster to get market validation 64 | - **Actions:** 65 | - [ ] @darcyclarke Schedule a working session to review Package Distributions & Optional Dependenyc Conditionals 66 | 7. **Issue**: [#438 [RRFC] Add libc fields to select optionalDependencies should be installed or skipped](https://github.com/npm/rfcs/issues/438) - @Brooooooklyn 67 | 68 | ### Other Topics 69 | 70 | - @ljharb where are we with staged releases? 71 | - @bnb `npm audit license` work? 72 | -------------------------------------------------------------------------------- /meetings/2020-06-10.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: June 10th, 2020 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Ruy Adorno (@ruyadorno) 8 | - Claudia Hernández (@claudiahdz) 9 | - Jordan Harband (@ljharb) 10 | - Tierney Cyren (@bnb) 11 | 12 | ### Agenda 13 | 14 | 1. **Housekeeping** 15 | 1. Introduction(s) 16 | 1. Code of Conduct Acknowledgement 17 | 1. Outline Intentions & Desired Outcomes 18 | 1. Announcements 19 | 1. **PR**: [#152 RFC: npm fund depth](https://github.com/npm/rfcs/pull/152) 20 | 1. **PR**: [#150 RFC: Add file+pack dependency protocol](https://github.com/npm/rfcs/pull/150) 21 | 1. **PR**: [#138 RFC: Add `npm-app-id` HTTP header](https://github.com/npm/rfcs/pull/138) 22 | 1. **PR**: [#129 RFC: overrides](https://github.com/npm/rfcs/pull/129) 23 | 1. **PR**: [#126 RFC: Adding types information to the Package JSON in the registry](https://github.com/npm/rfcs/pull/126) 24 | 1. **PR**: [#121 Added proposal for package version `link#\[version\](comment)` syntax](https://github.com/npm/rfcs/pull/121) 25 | 1. **PR**: [#117 RFC: npm workspaces - Running Commands](https://github.com/npm/rfcs/pull/117) 26 | 1. **PR**: [#18 npm audit resolve](https://github.com/npm/rfcs/pull/18) 27 | 1. **Added**: Update implemented RFCs to be moved over 28 | 29 | ### Notes 30 | 31 | ### npm fund depth 32 | - we are moving away from the `depth` flag in a number of different commands like `outdated`, `update` and probably `ls` too 33 | - the tree in fund is different from the normal tree and applying depth makes implementation more complex 34 | - depth seems to be used often as either all tree deps or direct deps 35 | - there should be more steps on how we prioritize the funding info on the CLI 36 | - how do we meaningfully show information that will actually lead to people funding contributors? 37 | - `npm fund` needs UX design and will be taken care of in the near future by proper designers 38 | - the things i depend the most are most times the most invicible in my project 39 | - we have to find better ways to show the use what they should be funding 40 | - RFC will receive feedback from the discussion 41 | 42 | ### Add file+pack dependency protocol 43 | - TBD next week 44 | 45 | ### Add `npm-app-id` HTTP header 46 | - wes had some ideas on expanding this RFC 47 | - should ping folks to move this RFC forward 48 | 49 | ### overrides 50 | - not expected to be shipped in v7 (maybe v7.1?) 51 | - should be mindful that feature lands on LTS versions 52 | 53 | ### Adding types information to the Package JSON in the registry 54 | - should ping author on status, but RFC looks good to go 55 | 56 | ### Added proposal for package version `link#version` syntax 57 | - author not on call, concerns on this feature considering the workspaces work that is in place alreadys 58 | 59 | ### npm workspaces - Running Commands 60 | - no news 61 | - ruy to be collecting feedback 62 | - there's a specific list of top-level commands supported by the RFC: https://github.com/npm/rfcs/pull/117/files#diff-828bb29c16ce81ff3a4108b6e8dab945R33 63 | - "everything should work the same way" - discussion on how we should be able to run all commands from the workspace 64 | - we should expand the subset of supported commands 65 | -------------------------------------------------------------------------------- /meetings/2020-08-19.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: August 19th, 2020 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Ruy Adorno (@ruyadorno) 7 | - Isaac Z. Schlueter (@isaacs) 8 | - Christian Siebmanns (@christian24) 9 | - Jordan Harband (@ljharb) 10 | - Myles Borins (@MylesBorins) 11 | - Lukas Spieß (@lumaxis) 12 | - Wes Todd (@wesleytodd) 13 | - Tierney Cyren (@bnb) 14 | 15 | ### Agenda 16 | 1. **Housekeeping** 17 | 1. Introduction(s) 18 | 1. Code of Conduct Acknowledgement 19 | 1. Outline Intentions & Desired Outcomes 20 | 1. Announcements 21 | 1. **PR**: [#129 RFC: overrides](https://github.com/npm/rfcs/pull/129) - @isaacs 22 | 1. **PR**: [#126 RFC: Adding types information to the Package JSON in the registry](https://github.com/npm/rfcs/pull/126) - @orta 23 | 1. **PR**: [#1674 Rfc 0027 npm audit app id](https://github.com/npm/cli/pull/1674) - @doddi 24 | 1. **PR**: [#1586 [Feature] Security Pipeline](https://github.com/npm/cli/pull/1586) - @jskoll 25 | 1. **Issue**: [#190 [RRFC] npm run-series && npm run-parallel](https://github.com/npm/rfcs/issues/190) - @MylesBorins 26 | 1. **PR**: [#185 RFC: Add ability to skip script hooks](https://github.com/npm/rfcs/pull/185) - @lumaxis 27 | 1. **PR**: [#183 RFC21: bring back subset of npm_package_* environs](https://github.com/npm/rfcs/pull/183) - @isaacs 28 | 1. **PR**: [#182 RFC: npm audit licenses](https://github.com/npm/rfcs/pull/182) - @bnb 29 | 1. **PR**: [#165 RFC for parent package.json](https://github.com/npm/rfcs/pull/165) - @Christian24 30 | 31 | ### Notes 32 | 33 | - overrides 34 | - wes: inheriting overrides from an external source? 35 | - isaacs: will be implied by RFC #165 parent package.json 36 | - types: not much updates, been heads-down on v7 37 | - appid 38 | - mark: doing audits tailored to each individual application 39 | - wes: would be nice to use for other general project/packge linting stuff 40 | - discussion of new audit bulk advisory endpoint vs quickaudit endpoint, scaling and perf 41 | - isaacs: not great to use audit to do project linting, but project linting is a good thing 42 | - send appid (or something) in header rather than POST request body 43 | - security pipeline 44 | - let's do this in v7, latest is known legacy outdated 45 | - run-series, run-parallel 46 | - punt, covered in last meeting 47 | - issues brought up, still pending discussion, but urgent. 48 | - move to remove from agenda until practical/speicfici to discuss 49 | - concerns about scope, series cleaner than parallel, one point about whether we want to make it more complicated at all 50 | - maybe drop parallel and just add series to have a platform-agnostic alternative to `&&` 51 | - add ability to skip script-hooks 52 | - isaacs: we should do this 53 | - isaacs: move to accepted today 54 | - bring back subset of npm_package_* environs 55 | - isaacs: not everything is being included anymore, but most are 56 | - isaacs: a custom node script can be used if you need everything 57 | - npm audit licenses 58 | - tierney: could use more feedback to help figure out next steps (written please) 59 | - discussion about the licensee project and how it can potentially be used 60 | - parent package.json 61 | - does not require first-class support from node 62 | - imports/exports not inherited (probably?) 63 | -------------------------------------------------------------------------------- /meetings/2022-02-02.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: February 2nd, 2022 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Rhys Arkins (@rarkins) 8 | - Ruy Adorno (@ruyadorno) 9 | - Jordan Harband (@ljharb) 10 | - Owen Buckley (@thescientist13) 11 | - Jean Burellier (@sheplu) 12 | 13 | ### Previously... 14 | 15 | - [2022-01-19](https://github.com/npm/rfcs/blob/main/meetings/2022-01-19.md) 16 | 17 | ### Agenda 18 | 19 | 1. **Housekeeping** 20 | 1. Introduction(s) 21 | 1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct) 22 | 1. Outline Intentions & Desired Outcomes 23 | 1. Announcements 24 | - OpenJS World 2022 25 | - https://events.linuxfoundation.org/openjs-world/ 26 | - CFP: https://events.linuxfoundation.org/openjs-world/program/cfp/ 27 | 1. **PR**: [#4335 Make 'npm install --loglevel warn' Output Quieter](https://github.com/npm/cli/pull/4335) - @DabeDotCom 28 | - @ruyadorno 29 | - want to have no output at the end of `install` 30 | - @lukekarrys 31 | - have been working on this 32 | - seems like a case by case for specific output 33 | 3. **PR**: [#516 RFC: Deprecated packages UX revamp](https://github.com/npm/rfcs/pull/516) - @ruyadorno 34 | - @ruyadorno 35 | - cleaning up output of `install` ever since v7 36 | - deprecation warnings are the last set not consolidated into a single line of output (ex. `found 9 deprecated packages & need your attention`) 37 | - `npm deprecated` | `npm deprecations` for listing current deprecation notices 38 | - @rarkins 39 | - @darcyclarke 40 | - add `--no-deprecations` opt-out flag 41 | - @ljharb 42 | - deprecation warnings for transitive dependencies should not be bubbled up 43 | - `npm deprecations <pkg>` to see current deprecation notices for a specific package 44 | - @ruyadorno 45 | - we talked about this before, to have `npm deprecations` work like `npm ls` & need `--all` to see everything 46 | 4. **PR**: [#4260 feat(arborist)(reify): add an ability to add a hook](https://github.com/npm/cli/pull/4260) - @fritzy 47 | - @rarkins 48 | - whitesource has been working on a tool that validates and prevents known malicious packages from getting installed during `npm install` 49 | 6. **Issue**: [#511 [RRFC] remove `npm-shrinkwrap.json` from the list of unignorable files](https://github.com/npm/rfcs/issues/511) - @ljharb 50 | 7. **PR**: [#4227 Change the default save-prefix from ^ to none](https://github.com/npm/cli/pull/4227) - @zkldi 51 | 8. **Issue**: [#482 [RRFC] npm should use stderr for errors](https://github.com/npm/rfcs/issues/482) - @exx8 52 | 9. **PR**: [#343 RFC: npm workspaces: auto switch context based on cwd](https://github.com/npm/rfcs/pull/343) - @ruyadorno 53 | 10. **PR**: [#519 RFC: Package Distributions](https://github.com/npm/rfcs/pull/519) - @darcyclarke 54 | - @ljharb would prefer to see the RFC tackle a more broad set of usecases for distributions/variants 55 | - @darcyclarke the current proposal is purposely very focused on a narrow set of usecases so that we can provide an optimal experience f... 56 | - @ruyadorno 57 | - this is essentially a first-step 58 | - this provides an initial set of distribution conditions 59 | - we can have future rfcs incrementing optionalDependencies / distributions 60 | -------------------------------------------------------------------------------- /meetings/2021-02-03.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: February 3rd, 2021 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Ruy Adorno (@ruyadorno) 8 | - Wes Todd (@wesleytodd) 9 | - Myles Borins (@MylesBorins) 10 | - Jordan Harband (@ljharb) 11 | - 12 | 13 | ### Agenda 14 | 15 | 1. **Housekeeping** 16 | 1. Introduction(s) 17 | 1. Code of Conduct Acknowledgement 18 | 1. Outline Intentions & Desired Outcomes 19 | 1. Announcements 20 | 1. **Feedback from npm v7 going to `latest`** 21 | 1. **Issue**: [#301 [RRFC] Workspaces: support to version specifiers other than semver ranges](https://github.com/npm/rfcs/issues/301) - @ruyadorno 22 | 1. **PR**: [#117 RFC: npm workspaces - Working with workspaces](https://github.com/npm/rfcs/pull/117) - @ruyadorno 23 | 24 | ### Notes 25 | 26 | * 1. **Feedback from npm v7 going to `latest`** 27 | * @ljharb has experienced some issues 28 | * currently investigating an issue between v6 & v7 29 | * build/tests are failinig (https://github.com/ljharb/eslint-plugin-import/runs/1817778513?check_suite_focus=true) 30 | * `eslint-plugin-import`: https://github.com/benmosher/eslint-plugin-import/issues/1986 31 | * anecdotally, believe it's the installation in the root of the package 32 | * @wesleytodd could be a bug in the webpack resolver 33 | 34 | * 2. **Announcements** 35 | * @ruyadorno `npm diff` launched (ref. https://dev.to/ruyadorno/npm-diff-23dh) 36 | * @wesleytodd Adam Baldwin has been posting about security vulnerabilities in the ecosystem (ref. https://evilpacket.net/2021/attacking-oss-using-abandoned-resources/) 37 | * @wesleytodd bug/issue ran prepare scripts with legacy/old `git` dep (deep transitive - `wdio`) - seems to be in `arborist.buildIdealTree` seems to run prepare script which could run in the cache 38 | 39 | * 3. **Workspaces** 40 | * Notes from last RFC call: https://github.com/npm/rfcs/blob/latest/meetings/2021-01-27.md#notes 41 | * @wesleytodd working with the Google folks that wrote `release-please` might be good 42 | * specifically, they are trying to run commands inside workspace projects programmatically (ie. utilizing `arborist` to get a list of workspaces/`package.json`s) 43 | * learn why/what they've been using `lerna` for 44 | * @wesleytodd have a bit of a unique workflow compared to `release-please` offers (would prefer `npm update` to be able to handle this better) 45 | * @darcyclarke pivot points seem to be around hoist 46 | * @ljharb `npm` needs to ship a non-breaking workspace implementation 47 | * @ruyadorno has heard some complaints about the basics w/ current workspaces, has some ideas... 48 | * @ruyadorno we should wait until v8 to change the workspace implementation 49 | * @darcyclarke keep thinking about the opt-in "strategy" for `strategies` (ie. host/shared/global-style/legacy-bundling) 50 | * @wesleytodd would love opt-in changes shipped 51 | * @ljharb minor makes sense since it should only be better/more-strict (nomenclature `mode`s ?) 52 | * @ruyadorno does a different `mode` how workspaces get installed? 53 | * @ruyadorno we may still want to consider including the `nohost` config that Yarn v1 had 54 | * @ruyadorno is it a good idea to start work on the running commands in workspaces before we surface this? 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | -------------------------------------------------------------------------------- /meetings/2020-07-08.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: July 8th, 2020 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Tierney Cyren (@bnb) 8 | - Ruy Adorno(@ruyadorno) 9 | - Claudia Hernández (@claudiahdz) 10 | - Glenn Hinks (@ghinks) 11 | - Jordan Harband (@ljharb) 12 | 13 | ### Agenda 14 | 15 | 1. **Housekeeping** 16 | 1. Introduction(s) 17 | 1. Code of Conduct Acknowledgement 18 | 1. Outline Intentions & Desired Outcomes 19 | 1. Announcements 20 | 1. **Issue**: [#160 [Poll] Preference on how to filter workspaces](https://github.com/npm/rfcs/issues/160) 21 | 1. **PR**: [#150 RFC: Add file+pack dependency protocol](https://github.com/npm/rfcs/pull/150) 22 | 1. **PR**: [#129 RFC: overrides](https://github.com/npm/rfcs/pull/129) 23 | 1. **PR**: [#126 RFC: Adding types information to the Package JSON in the registry](https://github.com/npm/rfcs/pull/126) 24 | 1. **PR**: [#117 RFC: npm workspaces - Running Commands](https://github.com/npm/rfcs/pull/117) 25 | 1. **PR**: [#18 npm audit resolve](https://github.com/npm/rfcs/pull/18) 26 | 1. Discuss adding folks to Community Maintainer Team (add/remove labels) 27 | 28 | ### Notes 29 | 30 | ### Preference on how to filter workspaces 31 | - This will probably land in a minor of v7 32 | - No rush on ratifying yet 33 | - The poll will stay open so people have more time to vote/comment 34 | 35 | ### Add file+pack dependency protocol 36 | - This RFC in a nutshell: You can currently list a dependency with using the file protocol and npm will create a symlink to that path. What this RFC wants is to specify a folder but instead of symlinking it we want to pack it in a tarball and then unpack it like if you were just installing it. Drawback, changes to that folder won't be visible immediatly unless you re-install 37 | - Main issue is install does not currently run prepare scripts (there's no building step) 38 | - Instead of adding a new protocol (file+pack) that is not backwards compatible, we could add a new flag that can rebuild before install. 39 | - RFC author couldn't make the call, the discussion will be push to next week 40 | 41 | ### overrides 42 | - Discussions on UX and how to specify overriden dependencies, dot as an object key is confusing 43 | - I want to override the state of dependecies of some module I'm using 44 | - Will probably land in a minor of v7 45 | - Besides the small UX discussion, everyone agrees to ratify this RFC already 46 | - Isaac will land it 47 | 48 | ### Adding types information to the Package JSON in the registry 49 | - Only comment from Jordan is we wouldn't want this field to be only boolean or only accepting relative paths 50 | - RFC author couldn't make the call, the discussion will be push to next week 51 | 52 | ### npm workspaces - Running Commands 53 | - Discussions on DX for workspace groups as cli arguments, `--` (double dashes) are usually flags for config options on npm, we believe we should be using positional arguments 54 | - Should be carfeul about using a star in a positional argument since this can be problematic 55 | 56 | ### npm audit resolve 57 | - A PR with a different approach was pushed to the CLI (https://github.com/npm/cli/pull/1494) 58 | - audit has been fully rewritten already 59 | 60 | ### Adding folks to Community Maintainer Team 61 | - Everyone agrees is a good idea, Darcy and Ed Thomson will collaborate on making this happen. -------------------------------------------------------------------------------- /accepted/0047-npm-diff-ignore-cr-at-eol.md: -------------------------------------------------------------------------------- 1 | # npm diff ignore CR at EOL 2 | 3 | ## Summary 4 | 5 | An option to ignore Carriage Return (CR) at the end of lines when performing npm diff. 6 | 7 | ## Motivation 8 | 9 | To improve `npm diff` on packages developed on different platforms. Currently 10 | there are scenarios where every line is shown as changed if you are comparing 11 | to a package that was developed on a different platform than yours. 12 | 13 | ## Detailed Explanation 14 | 15 | If you build a compiled package, e.g. with typescript `tsc` on windows, the 16 | output is produced with CRLF (Carriage Return, Line Feed) line endings. 17 | If you then build the same application on UNIX, the output is produced with 18 | LF line endings, as expected. 19 | 20 | The problem arises when you want to see if your newly produced package has 21 | any changes compared to another package, if that package was produced 22 | on another platform. 23 | 24 | If the package you are comparing to is built on Windows, while you are 25 | working in UNIX, every produced file will be different because of the different 26 | file endings. 27 | 28 | This problem is avoided in some cases when the files you are comparing are 29 | tracked by git, depending on your git `autocrlf` configuration. The 30 | scenarios where I've noticed this is when the files we are comparing are built 31 | locally and `.gitignore`d. 32 | 33 | I'm suggesting the flag `--diff-ignore-cr-at-eol`. This is quite a mouthful, 34 | but would be consistent with 35 | [`git diff --ignore-cr-at-eol`](https://github.com/git/git/commit/e9282f02b2f21118f3383608718e38efc3d967e1) 36 | introduced in 37 | [`git v2.16`](https://git-scm.com/docs/git-diff/2.16.6). 38 | 39 | ## Rationale and Alternatives 40 | 41 | * Packages have their lineendings normalized when downloaded/installed from 42 | the registry. 43 | 44 | Similiar to `git config core.autocrlf`, npm could also normalize line 45 | endings when installing on a Windows machine. By doing this, 46 | `npm diff` would always be comparing files that are normalized for windows. 47 | 48 | However this would be a big change with plenty of potential pitfall. It'd 49 | also become problematic if a Windows user had configured git to keep files 50 | with LF line endings and tried to compare to a package that npm would then 51 | normalize to CRLF, again causing diffs... 52 | 53 | ## Implementation 54 | 55 | A change to `libnpmdiff` to add a new option `diffIgnoreCRAtEOL` similiarly 56 | to the 57 | [`diffIgnoreAllSpace` option](https://github.com/npm/cli/blob/892b66eba9f21dbfbc250572d437141e39a6de24/workspaces/libnpmdiff/lib/format-diff.js#L76). 58 | However, as far as I can tell, 59 | [npmjs.com/diff](https://npmjs.com/diff)/[kpdecker/jsdiff](https://github.com/kpdecker/jsdiff/) 60 | does not have any option to do something like this. One option is to submit a 61 | PR to add this. 62 | 63 | Add the `--diff-ignore-cr-at-eol` configuration support to the npm cli and 64 | make sure `./lib/commands/diff.js` handles it as expected to `libnpmdiff`. 65 | 66 | ## Prior Art 67 | 68 | * As mentioned previously 69 | [`git diff --ignore-cr-at-eol`](https://github.com/git/git/commit/e9282f02b2f21118f3383608718e38efc3d967e1) 70 | 71 | * Gnu diffutils 72 | [`diff --strip-trailing-cr`](https://www.gnu.org/software/diffutils/manual/html_node/diff-Options.html#diff-Options) 73 | -------------------------------------------------------------------------------- /accepted/0007-publish-without-tag.md: -------------------------------------------------------------------------------- 1 | # Publish older versions without a tag 2 | 3 | ## Summary 4 | 5 | By default, running `npm publish` will update the `latest` tag so it points to the new version of the package being published (unless another tag is specified using `--tag <tag>`). 6 | 7 | This makes sense when publishing a new version of the package that has a higher version number than the current release tagged with `latest`. But it doesn't make sense when releasing a version number that's lower than the version currently tagged `latest`. 8 | 9 | Instead, `npm publish` should only update the `latest` tag if the package being published has a higher version number than the one currently tagged `latest`. 10 | 11 | ## Motivation 12 | 13 | If you publish an older version of a package - say a patch for an older major branch - this new version will today be automatically tagged `latest` and will be the default package downloaded when a user runs `npm install <pkg>`. The version will also be listed as the latest on npmjs.com. 14 | 15 | This is counter intuitive when publishing a patch to an older version of a package and normally _never_ what the publisher want. 16 | 17 | Worst case scenario is that the publisher doesn't notice that the `latest` tag have changed, and users of the package will now start downloading older versions of the package without knowing a newer version exist. 18 | 19 | ## Detailed Explanation 20 | 21 | If publishing a package whos version is less than the version tagged `latest`, the `latest` tag should not be updated unless specifically stated with `--tag latest`. 22 | 23 | ## Rationale and Alternatives 24 | 25 | Currently possible: 26 | 27 | - `npm publish --tag <tag>` - Publish using a tag 28 | - `npm publish --tag <tag> && npm dist-tag rm <pkg> <tag>` - Publish using a throwaway tag that can be removed afterwards 29 | 30 | Currently not possible, but would be an alternative solution: 31 | 32 | - `npm publish --no-tag` - Explicitly don't tag the release 33 | 34 | Publishing using an explicit tag can be seen as kind of a hack. It's not intuitive to users who are not well versed in npm internals. The alternative of introducing a `--no-tag` argument doesn't solve the problem for publishers who don't know about it (though it would be better than requiring publishers to use a tag). 35 | 36 | ## Implementation 37 | 38 | {{Give a high-level overview of implementation requirements and concerns. Be specific about areas of code that need to change, and what their potential effects are. Discuss which repositories and sub-components will be affected, and what its overall code effect might be.}} 39 | 40 | {{THIS SECTION IS REQUIRED FOR RATIFICATION -- you can skip it if you don't know the technical details when first submitting the proposal, but it must be there before it's accepted}} 41 | 42 | ## Prior Art 43 | 44 | {{This section is optional if there are no actual prior examples in other tools}} 45 | 46 | {{Discuss existing examples of this change in other tools, and how they've addressed various concerns discussed above, and what the effect of those decisions has been}} 47 | 48 | ## Unresolved Questions and Bikeshedding 49 | 50 | {{Write about any arbitrary decisions that need to be made (syntax, colors, formatting, minor UX decisions), and any questions for the proposal that have not been answered.}} 51 | 52 | {{THIS SECTION SHOULD BE REMOVED BEFORE RATIFICATION}} 53 | -------------------------------------------------------------------------------- /meetings/2020-09-23.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: September 23rd, 2019 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Christian Siebmanns (@christian24) 8 | - Wes Todd (@wesleytodd) 9 | - Mark Dodgson (@doddi) 10 | - Nathan LaFreniere (@nlf) 11 | - Jordan Harband (@ljharb) 12 | - Ruy Adorno (@ruyadorno) 13 | 14 | ### Agenda 15 | 1. **Housekeeping** 16 | 1. Introduction(s) 17 | 1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct) 18 | 1. Outline Intentions & Desired Outcomes 19 | 1. Announcements 20 | 1. **PR**: [#235 Allow server generated header values](https://github.com/npm/rfcs/pull/235) - @doddi 21 | 1. **PR**: [#232 npm audit for a not yet installed package](https://github.com/npm/rfcs/pull/232) - @Christian24 22 | 1. **PR**: [#136 Add strictPeerDeps, override ERESOLVE if not true](https://github.com/npm/arborist/pull/136) - @isaacs 23 | 1. **Issue**: [#225 RRFC: Add support to plugin dependencies](https://github.com/npm/rfcs/issues/225) - @mshima 24 | 1. **Issue**: [#238 RRFC: Deprecating npx](https://github.com/npm/rfcs/issues/238) - @ruyadorno 25 | 1. **Issue**: [#155 RRFC: Deprecated packages: automatically display dependents](https://github.com/npm/rfcs/issues/155) - @dandv 26 | 27 | ### Notes 28 | 29 | 1. **PR**: [#235 Allow server generated header values](https://github.com/npm/rfcs/pull/235) - @doddi 30 | * @ljharb: Question, is there any use case beyond setting an app-id? 31 | * @ljharb: Seems like the scope of this is too broad 32 | * Keep open for now 33 | * Request feedback from community 34 | 1. **PR**: [#138 RFC: Add configurable data to HTTP header](https://github.com/npm/rfcs/pull/138) - @Mykyta 35 | * Updates made by @doddi to reflect feedback 36 | * Keep open for now 37 | * Expect to ratify if no pushback by next call 38 | 1. **PR**: [#232 npm audit for a not yet installed package](https://github.com/npm/rfcs/pull/232) - @Christian24 39 | * @ruyadorno suggested opt-out 40 | * @ljharb notes we should try not to slow down `npm view` 41 | * @ruyadorno should consider where we want this information to live 42 | * @wesleytodd this solution doesn't seem to solve the problem of discovering what dependencies will have adisories in their tree 43 | * @wesleytodd sounds like there's two problems: get information about package's advisory before you instal it & after it's been installed 44 | * @ruyadorno this information should be on the website (npmjs.com) 45 | * @darcyclarke could change the name to try to be more specific about what is happening to `npm view` (ex. instead of `--audit` you could use `--`) 46 | * @darcyclarke sounds like we could/would have to support this through doing a dry run install/audit unless we made registry changes 47 | * Asking for feedback to be added in the comments themselves 48 | 1. **PR**: [#136 Add strictPeerDeps, override ERESOLVE if not true](https://github.com/npm/arborist/pull/136) - @isaacs 49 | * @ljharb we should break & evangelize change 50 | * @ljharb messaging/warning should be scary about breaking this in npm 8 51 | * @ruyadorno ask for RRFC for printing warnings 52 | * @ljharb note: there was a lot of discussion about crashing/scrictness & no RRFC/RFC for changing this to resolving/warning 53 | * @wesleytodd we should be mindful of where warnings actually live/use-cases (ie. clogging up logs in CI) 54 | -------------------------------------------------------------------------------- /meetings/2020-07-15.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: July 15th, 2020 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Ruy Adorno (@ruyadorno) 8 | - Orta Therox (@orta) 9 | - Isaac Z. Schlueter (@isaacs) 10 | - Claudia Hernández (@claudiahdz) 11 | - Myles Borins (@MylesBorins) 12 | - Jordan Harband (@ljharb) 13 | 14 | ### Agenda 15 | 1. **Housekeeping** 16 | 1. Introduction(s) 17 | 1. Code of Conduct Acknowledgement 18 | 1. Outline Intentions & Desired Outcomes 19 | 1. Announcements 20 | 1. **Issue**: [#160 [Poll] Preference on how to filter workspaces](https://github.com/npm/rfcs/issues/160) 21 | 1. **PR**: [#150 RFC: Add file+pack dependency protocol](https://github.com/npm/rfcs/pull/150) 22 | 1. **PR**: [#129 RFC: overrides](https://github.com/npm/rfcs/pull/129) 23 | 1. **PR**: [#96 RFC: Add publish confirmation prompt](https://github.com/npm/rfcs/pull/96) 24 | 1. **PR**: [#126 RFC: Adding types information to the Package JSON in the registry](https://github.com/npm/rfcs/pull/126) 25 | 1. **PR**: [#165 RFC: Parent package.json](https://github.com/npm/rfcs/pull/165) 26 | 1. **PR**: [#114 RFC: Expand list of ignored files](https://github.com/npm/rfcs/pull/114) 27 | 28 | ### Notes 29 | 30 | ### Preference on how to filter workspaces 31 | - Using a named argument like `npm --workspace=foo test` translates to adding a new config value and aliasing it to `-ws` would be easy 32 | - Adding `npm workspace` as a new command is also trivially easy 33 | - The third option doing `npm :foo test` means adding a new setting config and is potentially costly to implement. Isaac suggest staying away from it 34 | - Isaac leans towards keeping this as a config value 35 | - Poll will stay open for another week 36 | 37 | ### Add file+pack dependency protocol 38 | - How do we differentiate between wanting a local dep being symlinked or packed/unpacked? 39 | - We can do it at a project level were all files are symlinked or all are packed and in this scenario this could be handled with a config value 40 | - If it has to be per dependency, using a protocol might be better 41 | - Making it a config value makes implementation easier, few changes on CLI and Arborist 42 | - Next actions: change RFC from protocol to config flag 43 | 44 | ### overrides 45 | - We'll stick with `.` syntax instead of `@` sign 46 | - Will land after 7.0 47 | 48 | ### Add publish confirmation prompt 49 | - +1 ratified 50 | - queue up for 7.0? 51 | - it's opt-in, so not semver-major 52 | - isaacs: pushing back on anything in 7.0.0, could we do 7.x? 53 | 54 | ### Adding types information to the Package JSON in the registry 55 | - "waiting on npm to do the work" situation 56 | - next steps: add feedback on rfc, ratify and implementation 57 | 58 | ### Parent package.json 59 | - Allows a package.json to extend a parent package.json to share dependencies and more between multiple packages 60 | - Hard to implement, target to a lot of problems 61 | - The RFC will stand a bit longer to give people chance to take a look at it 62 | 63 | ### Expand list of ignored files 64 | - We should include files that could leak secrets (ex. `.env`) 65 | - Add a prompt confirmation before publish that shows you files that you don't want on your package (might need a different RFC) 66 | - Tierney suggests taking a close look at what Node currently ignores: https://github.com/github/gitignore/blob/master/Node.gitignore 67 | - Ruy to create a different RFC 68 | -------------------------------------------------------------------------------- /meetings/2021-09-29.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: September 29th, 2021 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Gar (@wraithgar) 8 | - Rick Markins (@rxmarbles) 9 | - Isaac Z. Schlueter (@isaacs) 10 | - Nathan Fritz (@fritzy) 11 | - Luke Karrys (@lukekarrys) 12 | - Jordan Harband (@ljharb) 13 | 14 | ### Previously... 15 | 16 | - [2021-09-22](https://github.com/npm/rfcs/blob/latest/meetings/2021-09-22.md) 17 | 18 | ### Agenda 19 | 20 | 1. **Housekeeping** 21 | 1. Introduction(s) 22 | 1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct) 23 | 1. Outline Intentions & Desired Outcomes 24 | 1. Announcements 25 | 1. **Issue**: [#445 ⚠️ [RRFC] Breaking changes for `npm@8`](https://github.com/npm/rfcs/issues/445) - @nlf 26 | 1. **PR**: [#422 RFC: audit assertions](https://github.com/npm/rfcs/pull/422) - @bnb 27 | 1. **Issue**: [#466 [RRFC] `npm publish --if-needed`](https://github.com/npm/rfcs/issues/466) - @ljharb 28 | 1. **PR**: [#434 Support package-lock.json v3 in npm 7](https://github.com/npm/rfcs/pull/434) - @remcohaszing 29 | 30 | ### Notes 31 | 32 | #### **Issue**: [#445 ⚠️ [RRFC] Breaking changes for `npm@8`](https://github.com/npm/rfcs/issues/445) - @nlf 33 | - @wraithgar 34 | - only update here is that `node-gyp` will also get update in `npm@8` 35 | 36 | #### **PR**: [#422 RFC: audit assertions](https://github.com/npm/rfcs/pull/422) - @bnb 37 | - @darcyclarke 38 | - no updates from last week (need to create new RFC) 39 | 40 | #### **Issue**: [#466 [RRFC] `npm publish --if-needed`](https://github.com/npm/rfcs/issues/466) - @ljharb 41 | - @ljharb 42 | - `npm publish` is not repeatable today 43 | - @isaacs 44 | - `npm publish` should just work this way 45 | - should have been a `PUT` & not a `POST` 46 | - `npm publish` checks for existing versions, so we'd have to add `--force` 47 | - @bnb 48 | - could this be adapted for `npm unpublish` 49 | - **Action:** 50 | - [ ] @darcyclarke backlog work item to add `--force` support to `publish` 51 | - [ ] @darcyclarke backlog work item to add repeatable publishes for the same `dist.shasum` 52 | 53 | #### **PR**: [#434 Support package-lock.json v3 in npm 7](https://github.com/npm/rfcs/pull/434) - @remcohaszing 54 | - @isaacs 55 | - **Action:** 56 | - [ ] @isaacs will review & ratify 57 | - [ ] @darcyclarke to backlog work item 58 | 59 | #### Changing to Cache dir away from global 60 | - @bnb 61 | - has been some feedback/comms around the usecase of setting `prefix` to a user owned dir vs. the default global path 62 | - this is mostly to address new users & their DX 63 | - @isaacs 64 | - you want node/npm in your path 65 | - @ljharb 66 | - ideally, new users aren't managing/installing node on their own (ex. node version managers, node installers etc.) 67 | - @wraithgar 68 | - it's in everyone's best interest to point new users to a version manager/tool 69 | 70 | #### New TLS Enforcement on the npm Registry 71 | - @ljharb 72 | - for `nvm`, it doesn't seem like there's any option to continue to support old versions of npm (ex. `npm@1`), node & run CI for them 73 | - @isaacs 74 | - the thing that is blocking is that the old version of node can no longer connect to the npm registry 75 | - only work around would be to compile node w/ a newer version of openssl 76 | - @ljharb 77 | - for security purposes what does this change help prevent 78 | 79 | -------------------------------------------------------------------------------- /implemented/0005-update-package-json.md: -------------------------------------------------------------------------------- 1 | # Change how `npm update` edits `package.json` 2 | 3 | ## Summary 4 | 5 | `package.json` should not be edited by `npm update` unnecessarily. When updating a package to a newer version that still satisfies the original range, package.json should not change. Only when updating to a range that does not satisfy the range specified in `package.json` should it be changed and saved to `package.json`. 6 | 7 | ## Motivation 8 | 9 | It's not expected that the ranges in `package.json` changes when running `npm update`. This was more clearly shown in `npm@5` when `--save` became the default behaviour. Previously, running `npm update` would not edit `package.json`. This unexpectedness also manifests itself in an especially bad way when updating packages that are specified with a non-standard range. For example, packages using tilde (~) when the project default is caret (^), since this will save the new range with the default. 10 | 11 | See https://github.com/npm/npm/issues/16813 for more on this specific issue. 12 | 13 | ## Detailed Explanation 14 | 15 | When given the following dependencies in `package.json` 16 | 17 | ```json 18 | { 19 | "tilde-package": "~1.0.0", 20 | "caret-package": "^1.0.0", 21 | "rc-with-caret-package": "^1.0.0-rc.0", 22 | "rc-package": "1.0.0-rc.0" 23 | } 24 | ``` 25 | 26 | and the following available versions for all packages: 27 | 28 | ```json 29 | ["1.0.0-rc.0", "1.0.0", "1.1.0", "2.0.0"] 30 | ``` 31 | 32 | - `npm update` should not edit `package.json` in any way 33 | - `npm update <package-name>` should not edit `package.json` in any way 34 | - `npm update <package-name>@latest` should result in `<package-name>` being updated to `^2.0.0` in `package.json`. 35 | 36 | ## Rationale and Alternatives 37 | 38 | 1. No longer defaulting `npm update` to `--save`. This is not a great idea, since it only hides the problem, it will still result in unexpected behaviour when using `--save`. 39 | 2. Make sure that npm keeps the range when updating. For example, updating `~1.0.0` when `1.0.1` is available will yield `~1.0.1`. This also solves some of the problems, but I don't think there is a good reason to update `package.json` when we are updating to a version that is compatible with our current range. 40 | 41 | ## Implementation 42 | 43 | I have not looked into the code yet, and would appreciate help or guidance with this. 44 | 45 | <!-- 46 | Give a high-level overview of implementation requirements and concerns. Be specific about areas of code that need to change, and what their potential effects are. Discuss which repositories and sub-components will be affected, and what its overall code effect might be. 47 | 48 | THIS SECTION IS REQUIRED FOR RATIFICATION -- you can skip it if you don't know the technical details when first submitting the proposal, but it must be there before it's accepted 49 | --> 50 | 51 | ## Prior Art 52 | 53 | ### Yarn 54 | 55 | Yarns `upgrade` command does pretty much the same thing. It never edits `package.json` unless a range (or `--latest`) is supplied when updating. IMO, the usability of `yarn upgrade` is better in this regard. 56 | 57 | ## Unresolved Questions and Bikeshedding 58 | 59 | Maybe at the same time add a `--latest` flag, similar to yarns? 60 | 61 | If `update` is to change, should other parts of it also change? Are there any other gripes with how the command works currently? Maybe something to do with how `--depth` works, I've considered that to be a bit weird sometimes? 62 | -------------------------------------------------------------------------------- /implemented/0016-set-script-command.md: -------------------------------------------------------------------------------- 1 | # Set script in package.json from command line 2 | 3 | 4 | ## Summary 5 | 6 | An `npm` command that lets you create a task in the scripts section of the `package.json`. 7 | 8 | **Example:** 9 | 10 | * `npm set-script start "http-server ."` 11 | 12 | 13 | ``` 14 | { 15 | "name": "whatever-was-already-here", 16 | "scripts": { 17 | "start": "http-server .", 18 | "test": "some existing value" 19 | }, 20 | ... 21 | } 22 | ``` 23 | 24 | ## Motivation 25 | 26 | Outside of personal daily use (which I think is worth it just for that), it would make educational uses much easier. 27 | 28 | When giving instructions in a classroom setting (like in workshops) or just in tutorials, I'd prefer to say this: 29 | 30 | > "Run **`npm install --save-dev nw`** and then run **`npm set-script start "nw ."`** then run **`npm start`**." 31 | 32 | The current way has more steps and is proned to error: 33 | 34 | > "Run **`npm install --save-dev nw`** then open the **`package.json`** file and add a **`scripts`** section with a **`start`** set to **`nw .`** then save that and go back to the command prompt/terminal and run **`npm start`**." 35 | 36 | Especially since the `npm install` portion could take a long time, so if they modify the `package.json` while the install is still ongoing then when it completes and adds the dependency to the `package.json` it will overrite what they had (happens all the time for me). 37 | 38 | 39 | ## Detailed Explanation 40 | 41 | I want to be able to do this, walk away, and come back and it be done and running: 42 | 43 | ``` 44 | npm init -y && npm install --save-dev http-server && npm set-script start "http-server ." && npm start 45 | ``` 46 | 47 | Colons and hyphens are common in script names. they would look like this: 48 | 49 | * `npm set-script test:e2e "nightwatch"` 50 | * `npm set-script test-unit "jest --config jest.config.js --coverage"` 51 | 52 | 53 | ## Rationale and Alternatives 54 | 55 | 1. I could do `npx nw .` but there is an expectation that projects should just be `npm install && npm start`. 56 | 1. I could manually edit the `package.json` and type in the script name and value in the scripts section. (current common approach) 57 | 1. Someone could make a Node module/script to solve this that would need to be globally installed. But I'm the one writing this RFC and even I would never use that. I'm especially opposed to this as I don't believe to do something this basic should require poluting the global PATH, so I would never mention it in a workshop, classroom, or tutorial. 58 | 59 | 60 | ## Implementation 61 | 62 | 1. Add new top-level command at `lib/set-script.js` 63 | 1. Require 2 arguments. First is the script name, second is command. 64 | 1. Parse the `package.json` as an object 65 | 1. If there is no `"scripts"` section, create it 66 | 1. If the script name is already in use, store it for a warning message 67 | 1. `manifest.scripts[scriptName] = value` 68 | 1. Convert back to a happy string and save over the `package.json` 69 | 1. If there was an existing script with a different value, output a warning message 70 | 71 | 72 | ## Prior Art 73 | 74 | The proposal of `set-script` is similar to the existing `--save` and `--save-dev` in the sense that it is a command followed by arguments that result in the modification of `package.json`. 75 | 76 | * `npm install --save-dev http-server` 77 | 78 | ``` 79 | { 80 | "name": "whatever-was-already-here", 81 | "devDependencies": { 82 | "http-server": "^1.0.0" 83 | }, 84 | ... 85 | } 86 | ``` 87 | -------------------------------------------------------------------------------- /meetings/2020-05-20.md: -------------------------------------------------------------------------------- 1 | 2 | #### Wednesday, May 20, 2020, 2:00 PM EST 3 | # Open RFC Meeting - Deep Dive 4 | 5 | ### Attendees 6 | 7 | - Darcy Clarke (@darcyclarke) 8 | - Isaac Z. Schlueter (@isaacs) 9 | - Jordan Harband (@ljharb) 10 | - Claudia Hernández (@claudiahdz) 11 | - Wes Todd (@wesleytodd) 12 | - Ruy Adorno (@ruyadorno) 13 | 14 | ### Agenda 15 | 16 | 1. **Housekeeping** 17 | 1. Introduction(s) 18 | 1. Code of Conduct Acknowledgement 19 | 1. Outline Intentions & Desired Outcomes 20 | 1. Announcements 21 | 1. Topic(s): 22 | 1. **PR**: [#135 Clarify/Outline the RFC Withdrawal Process & Amendment](https://github.com/npm/rfcs/pull/135) 23 | 1. **PR**: [#133 RFC: Remove --depth from npm outdated](https://github.com/npm/rfcs/pull/133) 24 | 1. **PR**: [#135 RFC: Add `npm-app-id` HTTP header](https://github.com/npm/rfcs/pull/138) 25 | 1. **PR**: [#144 RFC: npm diff](https://github.com/npm/rfcs/pull/144) 26 | 1. **PR**: [#146 RFC: Notification system for cli updates](https://github.com/npm/rfcs/pull/146) 27 | 1. **PR**: [#126 RFC: Adding types information to the Package JSON in the registry](https://github.com/npm/rfcs/pull/126) 28 | 1. **PR**: [#121 Added proposal for package version `link#[version]` syntax](https://github.com/npm/rfcs/pull/121) 29 | 1. **PR**: [#117 RFC: npm workspaces - Running Commands](https://github.com/npm/rfcs/pull/117) 30 | 31 | 32 | ### Notes: 33 | 34 | #### Clarify/Outline the RFC Withdrawal Process & Amendment 35 | - Ability to not implement something that we previously ratified 36 | - Ratified, Wes, Ruy and Isaacs thumbs up, no objections 37 | 38 | #### RFC: Remove --depth from npm outdated 39 | - No objections, doesn't seem to need any amendments 40 | - Adding a new `--all` flag on `outdated` affects all commands 41 | - There are other cases where we might want to use the `--all` flag (ex. `npm ls`) 42 | - `--all` is meaninfully different from other flags 43 | - Add physical AND logical paths? 44 | - Logical path is hard from an output point of view since there are manye entries per dep, potentially growing exponentially 45 | - The problem of finding logical paths might be solved by different tooling other than `npm outdated` 46 | 47 | #### RFC: Add `npm-app-id` HTTP header 48 | - HTTP header may contain `npm-app-id` variable which may be used in third-party applications 49 | - Provide a hook for assigning metadata to an application 50 | - "general purpose metadata hook" 51 | - What are the applications/risks? Applications go way beyond the audit example presented on the RFC 52 | - Wes to add more examples/comments to the existing discussion 53 | 54 | ### RFC: npm diff 55 | - Ability to compare two packages (local and/or in the registry) 56 | - Similar to `git diff` 57 | - Complementary to `npm outdated` 58 | - Thoughts on uses-cases, developer experience, etc 59 | - Things like `name-only`, similar to git diff (only changed file names) 60 | - Ruy doing a POC 61 | - npm argument parsing is different from git, so matching it exactly as git does might be tricky or not possible 62 | 63 | ### RFC: Notification system for cli updates 64 | - remove current update-notifier logic from the cli 65 | - cli send the user-agent, specifiying the current version of the cli and the server answers back in case there is an updated 66 | - state of the registry engineering resources makes it difficult to add new features to the registry right now 67 | 68 | ### RFC: Adding types information to the Package JSON in the registry 69 | - main feedback is that instead of just using a binary parameter make the "types" field more explicit -------------------------------------------------------------------------------- /withdrawn/0008-no-caret-prerelease-installs.md: -------------------------------------------------------------------------------- 1 | # Withdrawal Amendment 2 | 3 | - Current **npm cli** team is unlikely to implement this 4 | - The proposed change is an undesired change of established semantics of semver and how prereleases are handled 5 | - **NOTE:** Users looking for this behavior should be steered into using the already existing `save-exact` config option 6 | 7 | ## Relevant Resources 8 | 9 | Withdrawn consensus achieved during the [Wednesday, June 16, 2021 OpenRFC meeting](https://github.com/npm/rfcs/issues/399) 10 | - Meeting Notes: https://github.com/npm/rfcs/blob/515b8f310eb4605022c8b25849dfc9941f321885/meetings/2021-06-16.md 11 | - Video Recording: https://youtu.be/N6cEmHKPRfo 12 | 13 | # No Caret Ranges for Prerelease Installs 14 | 15 | ## Summary 16 | 17 | This proposal changes the default behavior of the install command to pin the package version, but only for a package that is tagged with a version that is a [prerelease](https://github.com/npm/node-semver#prerelease-tags) (and not add the [caret range](https://github.com/npm/node-semver#caret-ranges-123-025-004), `^`) 18 | 19 | ```sh 20 | # if this resolves to a prerelease such as 7.0.0-beta.52 21 | npm install @babel/core 22 | ``` 23 | 24 | results in 25 | 26 | ```diff 27 | "devDependencies": { 28 | - "@babel/core": "^7.0.0-beta.52" 29 | + "@babel/core": "7.0.0-beta.52" 30 | } 31 | ``` 32 | 33 | ## Motivation 34 | 35 | As mentioned in the `node-semver` [readme](https://github.com/npm/node-semver#prerelease-tags), package authors may intentionally use prerelease tags to signify instability and breaking changes (`-alpha`, `-beta`). 36 | 37 | However, when a user tries to install a package like `@babel/core` from the cli with `npm install`, the default behavior of `--save` or `--save-dev` to `package.json` applies the `^` in front of the version which will install the latest prerelease in subsequent installs. 38 | 39 | This may be an unexpected experience for end users, as they may not realize they have installed the prerelease version initially, or don't understand that a package author maybe in the midst of other breaking changes that a user would not want to automatically have to deal with on CI or locally. 40 | 41 | *Example issue*: https://github.com/babel/babel/issues/7786#issuecomment-383586020 42 | 43 | By changing the default behavior to pin to the latest version, a user won't be automatically opted into the latest version and will have to explicitly do it themselves. This way an end-user can decide when to upgrade. 44 | 45 | ## Detailed Explanation 46 | 47 | `npm install`, when writing to `package.json` (like with `--save` or `--save-dev`), should check with semver and only add the `^` if the version isn't a prerelease. I don't believe it should affect anything else. 48 | 49 | ## Rationale and Alternatives 50 | 51 | One alternative is for package authors to not actually use prerelease versions at all: they might always stick to a `0.x` versioning system, or only make major version bumps. 52 | 53 | Otherwise, each time someone reports an issue with different/incompatible versions the package author would tell them to change their `package.json` to remove `^`. 54 | 55 | ## Implementation 56 | 57 | See `Detailed Explanation`. Add another conditional when writing to `package.json` on `npm install` such that it uses `semver` to check if the version passed to `npm install` is a prerelease or not. 58 | 59 | Suggestion: modify https://github.com/npm/cli/blob/ab0f0260e5b6333f98062fb2d9f4f9954d3ee6cd/lib/install/deps.js#L303-L305 and add a conditional like `semver.prerelease(version) == null` 60 | -------------------------------------------------------------------------------- /implemented/0022-quieter-install-scripts.md: -------------------------------------------------------------------------------- 1 | # Silence successful npm pre/post/install scripts 2 | 3 | ## Summary 4 | 5 | `npm install` shows too much low level information which is unhelpful to 6 | most developers. When a build script succeeds (or when failure is ignored 7 | for optional dependencies), there should be no output. 8 | 9 | ## Motivation 10 | 11 | It is too difficult to tell if a `npm install` has worked or not. Users, 12 | especially new users, are confused at the output as it looks like something 13 | has gone wrong when everything runs just fine. 14 | 15 | Displaying this output also reduces options for performance improvements, 16 | as install scripts cannot be run in parallel. 17 | 18 | ## Detailed Explanation 19 | 20 | Historically, stdio is shared with child processes for all lifecycle 21 | scripts. However, this means that: 22 | 23 | 1. Output is shown even when the script is successful, which can be 24 | confusing if the user is not familiar with their dependency's build 25 | process, which might be excessively verbose. 26 | 2. Output is shown when the script fails, but for an optional dependency, 27 | which is doubly confusing, as the _install_ process succeded, but the 28 | terminal is full of errors. 29 | 3. Lifecycle scripts at install time cannot be effectively parallelized 30 | without interleaving output, making it useless anyway. 31 | 32 | Only show output from lifecycle scripts if the script exits in error, or 33 | if the output of the script is the explicit purpose of the command being 34 | run. 35 | 36 | In general, for any scripts related to the package in the local prefix, 37 | stdio _should_ be shared with the child process. For any dependencies, 38 | stdio should _not_ be shared with the child process. 39 | 40 | So, for example, if a user runs `npm test`, then the `test` script output 41 | should be printed directly to their terminal. However, if they install a 42 | package with a `postinstall` script, then that should _not_ be printed to 43 | their terminal. 44 | 45 | If a background script fails, then its output _must_ be included in the 46 | error that is displayed to the user. 47 | 48 | ## Drawbacks and Considerations 49 | 50 | Many CLI tools only print color if the `stdout` or `stderr` are a proper 51 | TTY file descriptor. If install script lifecycle events are run with a 52 | `pipe` stdio, then most install scripts will be less colorful. This is not 53 | considered a blocker at this time. 54 | 55 | Some developers use a `postinstall` script to print a banner on the user's 56 | terminal asking for project funding or other support. Despite the 57 | controverisal opionions around this practice, npm had taken no official 58 | stance, but recognized that it is both (a) annoying to many users, and (b) 59 | an important way for _other_ developers to continue to work on OSS. 60 | 61 | Prior to the introduction of `npm fund`, this was considered a blocker for 62 | silencing build scripts, as it would silence those pleas for funding. Now 63 | that `npm fund` is in widespread use by developers seeking funding, this is 64 | no longer a consideration. 65 | 66 | ## Rationale and Alternatives 67 | 68 | One alternative approach is to set the loglevel config to `silent`. 69 | However, this also hides errors that the user _ought_ to see, because they 70 | caused the install to fail. 71 | 72 | ## Implementation 73 | 74 | If everything worked, then do not show lifecycle script output from any 75 | package but that in the current local prefix. 76 | 77 | If anything relevant didn't work, then print the output from the failed 78 | build script. 79 | 80 | ## Prior Art 81 | 82 | yarn, pnpm 83 | -------------------------------------------------------------------------------- /meetings/2021-11-03.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: November 3rd, 2021 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Matt Hayes (@mysterycommand) 8 | - Luke Karrys (@lukekarrys) 9 | - Jordan Harband (@ljharb) 10 | - Owen Buckley (thescientist13) 11 | - Vincent Bailly (@VincentBailly) 12 | - Jonathan Creamer (@jcreamer898) 13 | 14 | ### Previously... 15 | 16 | - [2021-10-13](https://github.com/npm/rfcs/blob/latest/meetings/2021-10-13.md) 17 | 18 | ### Agenda 19 | 20 | 1. **Housekeeping** 21 | 1. Introduction(s) 22 | 1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct) 23 | 1. Outline Intentions & Desired Outcomes 24 | 1. Announcements 25 | 1. **PR**: [#481 RFC: Run `prepare` Scripts for Linked Bundled Dependencies](https://github.com/npm/rfcs/pull/481) - @mysterycommand 26 | 1. **PR**: [#375 Define which dependencies are shared among workspace projects](https://github.com/npm/rfcs/pull/375) - @isaacs 27 | 1. **PR**: [#484 More predictable peer dependency installation](https://github.com/npm/rfcs/pull/484) - @VincentBailly 28 | 1. **PR**: [#486 Resolved registry overrides](https://github.com/npm/rfcs/pull/486) - @everett1992 29 | 30 | ### Notes 31 | 32 | #### **PR**: [#481 RFC: Run `prepare` Scripts for Linked Bundled Dependencies](https://github.com/npm/rfcs/pull/481) - @mysterycommand 33 | - @mysterycommand 34 | - not update 35 | - need help with the implementation 36 | - **Actions:** 37 | - @darcyclarke to set up call/connection w/ Mike 38 | - @darcyclarke to share slack channel/orgs 39 | - @ljharb will write RFC in the next week or so 40 | 41 | #### **PR**: [#375 Define which dependencies are shared among workspace projects](https://github.com/npm/rfcs/pull/375) - @isaacs & **PR**: [#484 More predictable peer dependency installation](https://github.com/npm/rfcs/pull/484) - @VincentBailly 42 | - @isaacs 43 | - these changes have fallen out of the work to implement isolated mode 44 | - need to change the default 45 | - idea is to not hoist peers above the workspace boundary to resolve issues with conflicting peer sets 46 | - @ljharb 47 | - this seems like an improvement 48 | - this makes the delta between shared & not deps bettter 49 | - @isaacs 50 | - use cases: 51 | - workspaces are all parts of one "thing"/program/application 52 | - managing disparate projects in the same monorepo which don't have ovarlapping needs/deps 53 | - change is minimal 54 | - on isolated mode, it is a deterministic transform of any arbitrary tree, with the benefit of not loading any modules you don't explicit depend on 55 | - @ljharb 56 | - ideally, workspaces define how they are related to eachother &/or npm can infer the relationships between eachother 57 | - have been trying to standardize/champion that every peer dep should also be considered a devdep 58 | - question: pnpm/yarn+pnp support a mechanism where if an optional dep has an associative peerdepepenciesmeta record it makes it available, should npm support this or similar behaivour? 59 | - @isaacs 60 | - thats some weird behaviour 61 | - not sure the implications, but may be easy to support 62 | - we have an escape hatch already, where you can define the dep at the root-level 63 | - **Actions:** 64 | - @ljharb will write RFC in the next week or so (amending/adding to or showing a delta between this RFC) 65 | 66 | #### **PR**: [#486 Resolved registry overrides](https://github.com/npm/rfcs/pull/486) - @everett1992 67 | - @everett1992 68 | - resolved key in package lock is problematic for their usecase 69 | - **Actions:** 70 | - will keep on the agenda for now 71 | - will try to address async 72 | -------------------------------------------------------------------------------- /meetings/2022-05-25.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: May 25th, 2022 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Nathan LaFreniere (@nlf) 8 | - Jordan Harband (@ljharb) 9 | - Owen Buckley (@thescientist13) 10 | - Ruy Adorno (@ruyadorno) 11 | 12 | ### Agenda 13 | 14 | 1. **Housekeeping** 15 | 1. Introduction(s) 16 | 1. Code of Conduct Acknowledgement 17 | 1. Outline Intentions & Desired Outcomes 18 | 1. Announcements 19 | - [**v9 Roadmap**](https://github.com/npm/statusboard/issues/443) (Check it out) 20 | - OpenJS World - https://openjsf.org/openjs-world-2021/ 21 | 1. **PR**: [#593 Only Registry Tarballs](https://github.com/npm/rfcs/pull/593) - @thescientist13 22 | 1. **PR**: [#564 RFC: Dependency Selector Syntax & `npm query`](https://github.com/npm/rfcs/pull/564) - @darcyclarke 23 | 1. **Issue**: [#575 [FEATURE] run-script with workspaces should short-circuit on script error](https://github.com/npm/rfcs/issues/575) - @johndiiorio 24 | 25 | ### Notes 26 | 27 | #### **PR**: [#593 Only Registry Tarballs](https://github.com/npm/rfcs/pull/593) - @thescientist13 28 | - @thescientist13 29 | - Bringing in as an RFC the results of the conversations in the original RRFC issue (https://github.com/npm/rfcs/issues/581) discussed previously in these meetings 30 | - @ljharb 31 | - Thinks it's very important to handle five different modes: 32 | - silent 33 | - warn on indirect deps 34 | - warn on direct deps 35 | - warn on everything 36 | - fail on everything 37 | - @darcyclarke 38 | - Potential in the future for this to be augmented/have more granular control, once `npm query` lands 39 | - @ljharb 40 | - There's a need for more **npm** commands to be more granular on what packages they act on 41 | - @darcyclarke 42 | - Better to hold on for now on adding any new way to filter/group packages until we have `npm query` out and see how we can best serve all these scenarios in a more holistic way 43 | - Stick with 3 modes: 44 | - warn on any git dep (default) 45 | - silent (same as today, opt-in) 46 | - strict / fail on any git dep (opt-in) 47 | - @ljharb 48 | - Too strong on transitive dep maintainers to then switch to strict mode by default 49 | - Avoiding maintainer burnout should always be a priority 50 | - @darcyclarke 51 | - There was a research from @naugtur showing that there's less than 1% of usage of git deps within top 10K packages, [ref](https://github.com/naugtur/research/blob/036ed9c84257c5d22d9952f765b0c95fd0ca5d85/git-deps/gits.md). 52 | - Sounds like we're blocked on making a decision here until `npm query` is ready. 53 | - @ljharb 54 | - RFC should be worded to include any remote-dep that is not coming from the registry (local linked deps are ok) but remote tarballs should also be included 55 | - Should relate the RFC to `npm audit` instead of tie it to `npm install` then it becomes auditing of dependency types (or similar), then install can one day maybe become configurable to failing if audit (or type audit) fails 56 | - @thescientist13 57 | - Will clean the RFC up and incorporate all the feedback 58 | 59 | #### **PR**: [#564 RFC: Dependency Selector Syntax & `npm query`](https://github.com/npm/rfcs/pull/564) - @darcyclarke 60 | - @ruyadorno 61 | - will demo something next week 62 | 63 | #### **Issue**: [#575 [FEATURE] run-script with workspaces should short-circuit on script error](https://github.com/npm/rfcs/issues/575) - @johndiiorio 64 | - @darcyclarke 65 | - discussed this at length in other calls 66 | - have backlogged work items to address this (ie. fail fast flag & topolgoical workspace ordering) 67 | - removing from the agenda 68 | 69 | 70 | -------------------------------------------------------------------------------- /meetings/2022-06-29.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: June 29th, 2022 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Jordan Harband (@ljharb) 8 | - Jon Jensen (@jenseng) 9 | - Owen Buckley (@thescientist13) 10 | 11 | ### Agenda 12 | 13 | 1. **Housekeeping** 14 | 1. Introduction(s) 15 | 1. Code of Conduct Acknowledgement 16 | 1. Outline Intentions & Desired Outcomes 17 | 1. Announcements 18 | 1. **PR**: [#91 feat(git): add support for :: in #committish](https://github.com/npm/npm-package-arg/pull/91) - @wraithgar 19 | 1. **Issue**: [#519 BREAKING CHANGE(engines): engines support for npm9](https://github.com/npm/statusboard/issues/519) - @lukekarrys 20 | 1. **PR**: [#5000 feat: add npm query cmd](https://github.com/npm/cli/pull/5000) - @ruyadorno 21 | 1. **PR**: [#595 Propose backwards-compatible improvements to compression](https://github.com/npm/rfcs/pull/595) - @EvanHahn 22 | 1. **PR**: [#593 Only Registry Tarballs](https://github.com/npm/rfcs/pull/593) - @thescientist13 23 | 1. **PR**: [#591 RFC: Registry-scoped keyfile / certfile credential options](https://github.com/npm/rfcs/pull/591) - @jenseng 24 | 1. **Issue**: [#489 Initiative: `v8.x`](https://github.com/npm/statusboard/issues/489) - @darcyclarke 25 | 1. **Issue**: [#487 Initiative: `v10.x`](https://github.com/npm/statusboard/issues/487) - @darcyclarke 26 | 1. **PR**: [#564 RFC: Dependency Selector Syntax & `npm query`](https://github.com/npm/rfcs/pull/564) - @darcyclarke 27 | 1. **Issue**: [#443 Initiative: `v9.x`](https://github.com/npm/statusboard/issues/443) - @darcyclarke 28 | 1. **PR**: [#165 RFC for parent package.json](https://github.com/npm/rfcs/pull/165) - @Christian24 29 | 30 | ### Notes 31 | 32 | #### **PR**: [#91 feat(git): add support for :: in #committish](https://github.com/npm/npm-package-arg/pull/91) - @wraithgar 33 | - Remove from agenda 34 | 35 | #### **Issue**: [#519 BREAKING CHANGE(engines): engines support for npm9](https://github.com/npm/statusboard/issues/519) - @lukekarrys 36 | - Remove from agenda 37 | 38 | #### **PR**: [#5000 feat: add npm query cmd](https://github.com/npm/cli/pull/5000) - @ruyadorno 39 | - @ljharb 40 | - ensure that the query selector syntax is being versioned & parsed in a downstream lib so you can change that vs. having that contract live in the `cli` 41 | 42 | #### **PR**: [#595 Propose backwards-compatible improvements to compression](https://github.com/npm/rfcs/pull/595) - @EvanHahn 43 | - Keep on agenda for now (WIP & research still on going) 44 | 45 | #### **PR**: [#593 Only Registry Tarballs](https://github.com/npm/rfcs/pull/593) - @thescientist13 46 | - @thescientist13 47 | - waiting on `npm query` 48 | - wondering if we should close this PR / start something new 49 | - @ljharb 50 | - we should always have nice shorthands for queries 51 | 52 | #### **PR**: [#591 RFC: Registry-scoped keyfile / certfile credential options](https://github.com/npm/rfcs/pull/591) - @jenseng 53 | - @jenseng 54 | - still working on implementation, can go ahead 55 | 56 | #### **Issue**: [#489 Initiative: `v8.x`](https://github.com/npm/statusboard/issues/489) - @darcyclarke 57 | - 58 | 59 | #### **Issue**: [#443 Initiative: `v9.x`](https://github.com/npm/statusboard/issues/443) - @darcyclarke 60 | - 61 | 62 | #### **Issue**: [#487 Initiative: `v10.x`](https://github.com/npm/statusboard/issues/487) - @darcyclarke 63 | - 64 | 65 | #### **PR**: [#564 RFC: Dependency Selector Syntax & `npm query`](https://github.com/npm/rfcs/pull/564) - @darcyclarke 66 | - 67 | 68 | #### **PR**: [#165 RFC for parent package.json](https://github.com/npm/rfcs/pull/165) - @Christian24 69 | -------------------------------------------------------------------------------- /meetings/2020-10-07.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: October 7th, 2020 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Isaac Z. Schlueter (@isaacs) 8 | - Ruy Adorno (@ruyadorno) 9 | - Christian Siebmanns (@christian24) 10 | - Jordan Harband (@ljharb) 11 | - Wes Todd (@wesleytodd) 12 | 13 | ### Agenda 14 | 1. **Housekeeping** 15 | 1. Introduction(s) 16 | 1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct) 17 | 1. Outline Intentions & Desired Outcomes 18 | 1. Announcements 19 | 1. **PR**: [#239 describe how npm 7 handles peer conflicts](https://github.com/npm/rfcs/pull/239) - @isaacs 20 | 21 | ### Notes 22 | 23 | - **PR**: [#239 describe how npm 7 handles peer conflicts](https://github.com/npm/rfcs/pull/239) - @isaacs 24 | - @isaacs 25 | - overarching want/need is for deps to install properly 26 | - users don't want conflicts but do want high quality 27 | - easiest way out of resolving conflicts is to just not install peerDeps (not realistic) 28 | - @ljharb 29 | - upgrade path from 6 to 7 shouldn't break someone 30 | - installing/updating a dep in a strict 7 dep graph should block/break when there's conflict 31 | - not sure how to reconcile strict vs. noisey 32 | - @isaacs 33 | - we could output a warning/notice to tell consumer to run w/ -f or fix their conflicts 34 | - @ljharb 35 | - potentially introduce a config value for suppressing warnings 36 | - @christian24 37 | - wants a config value to set the type of resolution in `.npmrc` 38 | - @isaacs 39 | - we have that today w/ `strict-peer-deps = true` or `npm config set strict-peer-deps` 40 | - @christian24 41 | - a lot of builds are happening in CI so a lot of notifications are silenced 42 | - @isaacs 43 | - developer do eventually see these on their local machines 44 | - @ruyadorno 45 | - what happens when you competiting versions of a dep, does the higher in the tree win? 46 | - @isaacs 47 | - example: 48 | - x@1 49 | - y@2 50 | - PEER(w@1) 51 | - z@1 52 | - PEER(w@2) 53 | - should always take the version of dependency that was defined by the user over a peer dep 54 | - previously, we would not have installed `w` at all which would have probably broke your app before 55 | - @ruyadorno 56 | - can we just place the deep dep into the top level dep to allow users to understand/update easier 57 | - @isaacs 58 | - would this not introduce conflicts with your primary deps which would crash 59 | - you can't really fix this peer dep since its transitive 60 | - less concerned about conflicts that are many levels deep 61 | - warnings should be stored & only output at the end of install (question via @christian24) 62 | - @ljharb 63 | - `install` with no arguments would install correctly 64 | - `install x` would fail as you're trying to modify/add the dep 65 | - wants to ensure once your graph is valid, you can't make it invalid 66 | - @isaacs 67 | - note: npm@7 does introduce a hidden "lockfile" similar to pnpm & yarn 68 | - change to this RFC to make is meta dependency we will grab the first thing we find 69 | - can we infer stictness when adding new deps? 70 | - should create a separate RFC for peer deep strictness modes & how conflicts resolve in specific situations (ie. `install` vs. `install x`) 71 | - update RFC & ratify 72 | - fix Arborist bug to align with the RFC 73 | - open a new RFC for changing the default strictness mode in `npm@8` 74 | -------------------------------------------------------------------------------- /meetings/2020-11-25.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: November 25th, 2020 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Christian Siebmanns (@christian24) 8 | - Ruy Adorno (@ruyadorno) 9 | - Isaac Z. Schlueter (@isaacs) 10 | 11 | ### Agenda 12 | 13 | 1. **Housekeeping** 14 | 1. Introduction(s) 15 | 1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct) 16 | 1. Announcements 17 | 1. **Issue**: [#287 [RRFC] Add nohoist option for workspaces](https://github.com/npm/rfcs/issues/287) - @socialwyze-franklin 18 | 1. **PR**: [#279 RFC for --default-command](https://github.com/npm/rfcs/pull/279) - @isaacs 19 | 1. **Issue**: [#275 [RRFC] `registry:<url>:<name>[@<version-range>]` dependency specifier](https://github.com/npm/rfcs/issues/275) - @isaacs 20 | 1. **PR**: [#273 RFC: npm workspaces - Config management](https://github.com/npm/rfcs/pull/273) - @ruyadorno 21 | 1. **PR**: [#272 RFC: add preferDev field to package.json](https://github.com/npm/rfcs/pull/272) - @Ginden 22 | 1. **PR**: [#217 RFC: add registry per package per organisation](https://github.com/npm/rfcs/pull/217) - @baloran 23 | 24 | ### Notes 25 | 26 | #### **Issue**: [#287 [RRFC] Add nohoist option for workspaces](https://github.com/npm/rfcs/issues/287) - @socialwyze-franklin 27 | - Action: queue up a proper RFC and deep dive for "hoisting"/reifying "strategies" 28 | 29 | #### **PR**: [#279 RFC for --default-command](https://github.com/npm/rfcs/pull/279) - @isaacs 30 | - Reminder from last conversation: 31 | - It may be disruptive 32 | - Sharing commands might become more challenging 33 | - Make the current default help-behavior a little bit more helpful, adding a note in case there's a script with that name 34 | - Default `npm` behavior takes from the old-days of clis having the default behavior be just print help output, similar to (`curl`, `tar`, etc) 35 | - @christian24: The diff binary (e.g: `npr`) would make it so that we avoid the namespace-conflict situation 36 | - @darcyclarke: Limitting the future new subcommands we could possibly add is one of the major inconvenients 37 | - @isaacs: `npm start`, `npm stop`, `npm restart` were added very early on in the cli and might have been better to never have had it in the first place 38 | - @ruyadorno: Not necessarily onboard with the idea of adding new binaries such as `npr`, still think it's better for aliases to live in userland packages, bash profiles, etc. 39 | - @darcyclarke: builtin binaires provide a good value for the new/intermediate developers since it provides a sane default behavior with no need to tweak configs 40 | 41 | #### **Issue**: [#275 [RRFC] `registry:<url>:<name>[@<version-range>]` dependency specifier](https://github.com/npm/rfcs/issues/275) - @isaacs 42 | - @isaacs: Seems to be quite actionable and uncontrovertial, need to write down the spec now 43 | 44 | #### **PR**: [#273 RFC: npm workspaces - Config management](https://github.com/npm/rfcs/pull/273) - @ruyadorno 45 | - @ruyadorno: From last call, listing workspaces is non-controvertial and very actionable but adding/removing workspaces is still up in the air since there were concerns brought up during the last time we discussed it 46 | - @ruyadorno: We need to collect more feedback and evolve this RFC 47 | 48 | #### **PR**: [#272 RFC: add preferDev field to package.json](https://github.com/npm/rfcs/pull/272) - @Ginden 49 | 50 | #### **PR**: [#217 RFC: add registry per package per organisation](https://github.com/npm/rfcs/pull/217) - @baloran 51 | - @darcyclarke: This is the preceding PR to [#275](https://github.com/npm/rfcs/issues/275) dependency specifier. We should circle back to this once work there is done. 52 | -------------------------------------------------------------------------------- /meetings/2020-02-05.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: February 5th, 2020 2 | # Open RFC Meeting (npm) 3 | 4 | ### Attendees: 5 | 6 | - Darcy Clarke (@darcyclarke) 7 | - Isaac Z. Schlueter (@izs) 8 | - Michael Perrotte (@mikemimik) 9 | - Wes Todd (@wesleytodd) 10 | - Claudia Hernández (@claudiahdz) 11 | 12 | ### Agenda: 13 | 14 | - Housekeeping (introductions, outlining intentions & desired outcomes) 15 | - Code of Conduct: https://www.npmjs.com/policies/conduct 16 | - PR: #68 RFC: Multiple Funding Sources 17 | - PR: #92 RFC: Add staging workflow for CI and human interoperability 18 | - PR: #90 RFC: reduce lifecycle script environment size 19 | - PR: #81 remove --depth from npm update 20 | - PR: #76 rfc: Signed Packuments 21 | - Issue: #75 [FEATURE] prompt for module type as part of npm init 22 | - PR: #46 feat(git): add support for ::subdir in #committish 23 | - PR: #73 RFC for npm run to traverse directory tree up to the root before failing 24 | - PR: #71 RFC: Verified Account Linking 25 | - Issue: #506 [BUG] npm audit places false blame 26 | - PR: #96 RFC: Add publish confirmation prompt 27 | 28 | ### Notes: 29 | 30 | - [1.a] speak to the code of conduct; we have one, please take a look at it 31 | - [2] no qualms 32 | - [2] will need to backlog for wubwub to support multiple funding sources on the website 33 | - [2] (ACTION): Darcy to create ticket representing this work 34 | - [3] Q: RFC talks about user permission, no where in the RFC does it mention how does it manage 2FA 35 | - [3] Implied that the auth token will bypass 2FA (limited permissions) 36 | - [3] Q: terminology “packages” 37 | - [3] you would have only one “instance” of a package at a version semver 38 | - [3] Might need to clarify this in the RFC 39 | - [3] how does that interplay with semver? 40 | - [3] Term: packument = metadata of a package 41 | - [3] meta around publish and promote; should capture the user who does these actions 42 | - [3] `npm_user` is the person who published it 43 | - [3] Q: who promoted it? 44 | - [3] Add new field for who promoted the package instance from a staged version to a published version 45 | - [3] lets say a developers machine is compromised, you want to be able to go through and find all possible packages they published as per an audit flow 46 | - [3] part of the complexity of delivering this, ironing out the details around auth tokens and permissions. Different set of users who are allowed to publish / promote 47 | - [3] there is some yaks to shave to get the details for the registry ironed out 48 | - [3] ship with just “all users who have publish, will also have promote”; first step (better than nothing, and waiting until perfect) 49 | - [3] mini viable server support, corgi / packument sync (staged versions) 50 | - [3] ACL will be tricky; in addition to 2FA 51 | - [3] location of tarballs will have to be though; due to cache timeouts 52 | - [3] ACTION(isaacs) write up considerations for package artifact urls, staged package urls, impacts on lockfiles, what happens when a staged version is updated/promoted between lockfile creation and usage. 53 | - [4] we’re going to be selective about what “stuff” we pass into the environment when running npm scripts 54 | - [4] already in arborist, there are some new environment variables being added to the run of the npm scripts 55 | - [4] `npm_command` seems to be like a main variable to add (or keep?) 56 | - [5] “depth” is not what you might think 57 | - [5] since we’re deduping and moving packages to the root of the tree 58 | - [5] you can have packages at different logical deps 59 | - [5] if we do update a module at a depth, that can change the depth another module of that name is now found (because of deduping and semver) 60 | - [5] `npm update foo` should now update all modules named `foo` 61 | -------------------------------------------------------------------------------- /meetings/2021-12-15.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: December 15th, 2021 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Matt Hayes (@mysterycommand) 8 | - Owen Buckley (@thescientist13) 9 | - Luke Karrys (@lukekarrys) 10 | - Zbyszek Tenerowicz (@naugtur) 11 | 12 | ### Previously... 13 | 14 | - [2021-11-25](https://github.com/npm/rfcs/blob/latest/meetings/2021-11-25.md) 15 | 16 | ### Agenda 17 | 18 | 1. **Housekeeping** 19 | 1. Introduction(s) 20 | 1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct) 21 | 1. Outline Intentions & Desired Outcomes 22 | 1. Announcements 23 | - overrides shipped 24 | 1. **Issue**: [#497 [RRFC] Warn users when skipping alias/git deps during audit](https://github.com/npm/rfcs/issues/497) - @rotem-cider 25 | 1. **Issue**: [#999 [RRFC] Custom logging location ](https://github.com/npm/rfcs/issues/499) - @EvanCarroll 26 | 1. **Dsicussion**: [#496 Mention workspace in run-script output header](https://github.com/npm/rfcs/discussions/496) - @smhg 27 | 1. **PR**: [#488 Make npm install scripts opt-in](https://github.com/npm/rfcs/pull/488) - @tolmasky 28 | 1. **PR**: [#481 RFC: Run `prepare` Scripts for Linked Bundled Dependencies](https://github.com/npm/rfcs/pull/481) - @mysterycommand 29 | 1. **PR**: [#375 Define which dependencies are shared among workspace projects](https://github.com/npm/rfcs/pull/375) - @isaacs 30 | 31 | 32 | ### Notes 33 | 34 | #### **Issue**: [#497 [RRFC] Warn users when skipping alias/git deps during audit](https://github.com/npm/rfcs/issues/497) - @rotem-cider 35 | - @darcyclarke 36 | - we're planning to revamp `npm audit` & `npm install` output to make this issue less relevant 37 | - explicitely defining which deps get audited & whu will help mitigate confusion 38 | 39 | #### **Issue**: [#999 [RRFC] Custom logging location ](https://github.com/npm/rfcs/issues/499) - @EvanCarroll 40 | - @lukekarrys 41 | - currently `npm` owns the cach directory 42 | - we're looking to separate the logs from the cache/log directory 43 | - we will only let you determine the directory path & not the file name 44 | - :+1: to this - is a net-new flag 45 | - @fritzy 46 | - we should maybe name this appropriately like, `--unmanagedLogDir` or something similar 47 | 48 | #### **Discussion**: [#496 Mention workspace in run-script output header](https://github.com/npm/rfcs/discussions/496) - @smhg 49 | - ... 50 | 51 | - @darcyclarke 52 | - :+1: for this 53 | - aligns with the work we'd like to do 54 | - @lukekarrys 55 | - likes this 56 | - would have treated this like a bug fix if it didn't come through discussions 57 | - prefixing is very interesting/compelling as well 58 | - @naugtur 59 | - can `publish --dry-run` support this aswell? 60 | - @darcyclarke 61 | - yes, let's have any workspace-aware command support logging the context 62 | 63 | #### **PR**: [#481 RFC: Run `prepare` Scripts for Linked Bundled Dependencies](https://github.com/npm/rfcs/pull/481) - @mysterycommand 64 | - @mysterycommand 65 | - no update 66 | - was able to get a hacky work around for this 67 | - only works one level deep 68 | - @fritzy 69 | - 70 | - @darcyclarke 71 | - sounds like `yarn` doesn't support this either 72 | - **Actions:** 73 | - [ ] @mysterycommand to investigate how yarn handles this 74 | - [ ] @darcyclarke to investigate https://turborepo.org/docs/features/pipelines 75 | 76 | #### **PR**: [#488 Make npm install scripts opt-in](https://github.com/npm/rfcs/pull/488) - @tolmasky 77 | - @naugtur 78 | - has done some investigation here 79 | - worked with maintainer of lavamoat 80 | 81 | #### **PR**: [#375 Define which dependencies are shared among workspace projects](https://github.com/npm/rfcs/pull/375) - @isaacs 82 | - ... 83 | -------------------------------------------------------------------------------- /accepted/0037-audit-overrides.md: -------------------------------------------------------------------------------- 1 | # npm audit fix can apply overrides 2 | 3 | ## Summary 4 | 5 | Allow npm audit fix to, in addition to updating versions in the dependency 6 | tree, add overrides to a project's package.json to allow for non-semver 7 | compatible security fixes. 8 | 9 | ## Motivation 10 | 11 | Currently security updates are limited to patches provided by the original 12 | authors. This means automatic fixes are impossible if the package is no 13 | longer maintained or patches include other changes that are undesirable. 14 | 15 | ## Rationale and Alternatives 16 | 17 | Being able to apply hotfix patches allows for security updates to be 18 | deployed faster and sometimes, at all. Without this, advice when a package 19 | is unmaintained and has a security vulnerability is to switch to a fork, 20 | but that's time consuming and difficult, particularly when the package is a 21 | transitive dependency. This means that even conscientious teams may take an 22 | extended period of time to apply updates. 23 | 24 | This sort of feature exists in some third party tools (eg Synk) but they 25 | have to subvert npm's own integrity protections to make that possible. 26 | 27 | For the purposes of transparency, to be clear the original motivation for 28 | this RFC is to provide large enterprises (eg Microsoft) with a facility in 29 | the tool to allow them to provide their employees with internally patched 30 | or rebuilt versions of dependencies. (Current tooling, like Synk, subverts 31 | npm's expectations in ways that are potentially fragile.) 32 | 33 | ## Scenario 34 | 35 | ### "Hot fixes" 36 | 37 | A critical security flaw is found in a dependency of one of your 38 | dependencies. The author of the transitive dependency is unavailable to 39 | provide updates. The package is widely used in your organization, usually 40 | as a transitive dependency. The ecosystem will eventually switch to another 41 | module. In the meantime you need some remediation. 42 | 43 | You instruct your private registry to provide audit results for the 44 | affected versions of the module that indicate that a custom patched version 45 | is available, something like: 46 | 47 | ``` 48 | { 49 | "example": [ 50 | { 51 | "id": 99999, 52 | "severity": "high", 53 | "title": "Remote Code Execution", 54 | "url": "https://npmjs.com/advisories/99999", 55 | "vulnerable_versions": "<=3.0.1", 56 | "overrides": { 57 | "3.0.0": "npm:@company/example-patched@3.0.0" 58 | } 59 | } 60 | ] 61 | } 62 | ``` 63 | 64 | This instructs `npm audit fix` to add an overrides section to your 65 | `package.json` like: 66 | 67 | ``` 68 | "overrides": { 69 | "example@3.0.0": "npm:@company/example-patched@3.0.0" 70 | } 71 | ``` 72 | 73 | ## Implementation 74 | 75 | This obviously can't be a thing until overrides lands in npm itself. 76 | 77 | Updating the npm audit report library may be required. 78 | 79 | Updating the `npm audit fix` subcommand will be necessary. 80 | 81 | Out of scope: Updating the npm audit end point to start giving this advice. 82 | It may or may not be desirable for the team that provides security advice 83 | for that end point, but that's ultimately up to them. 84 | 85 | ## Compatibility 86 | 87 | If the server initially implements this solely in the batch advisory 88 | endpoint, then it will be simply ignored by older clients that do not 89 | support overrides. 90 | 91 | New clients _must not_ crash or exhibit other undesirable behavior if the 92 | `overrides` key is missing from an advisory result object. 93 | 94 | If the server adds an `overrides` section to the legacy advisory endpoint, 95 | then this will be ignored by clients that do not support audit overrides 96 | already. 97 | -------------------------------------------------------------------------------- /meetings/2021-10-06.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: October 6th, 2021 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Nathan Fritz (@fritzy) 8 | - Matt Hayes (@mysterycommand) 9 | - Gar (@wraithgar) 10 | - Jordan Harband (@ljharb) 11 | - Rick Markins (@rxmarbles) 12 | 13 | ### Previously... 14 | 15 | - [2021-09-29](https://github.com/npm/rfcs/blob/latest/meetings/2021-09-29.md) 16 | 17 | ### Agenda 18 | 19 | 1. **Housekeeping** 20 | 1. Introduction(s) 21 | 1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct) 22 | 1. Outline Intentions & Desired Outcomes 23 | 1. Announcements 24 | 1. **Issue**: [#466 [RRFC] `npm publish --if-needed`](https://github.com/npm/rfcs/issues/466) - @ljharb 25 | 1. **Issue**: [#463 [RRFC] Multi-app Monorepo Support](https://github.com/npm/rfcs/issues/463) - @mysterycommand 26 | 1. **Tree Mutation Event** 27 | 1. **Issue**: [#445 ⚠️ [RRFC] Breaking changes for `npm@8`](https://github.com/npm/rfcs/issues/445) - @nlf 28 | 29 | ### Notes 30 | 31 | #### **Issue**: [#466 [RRFC] `npm publish --if-needed`](https://github.com/npm/rfcs/issues/466) - @ljharb 32 | - **Action:** 33 | - @darcyclarke to remove label 34 | - @darcyclarke to backlog work for CLI team 35 | 36 | #### **Issue**: [#463 [RRFC] Multi-app Monorepo Support](https://github.com/npm/rfcs/issues/463) - @mysterycommand 37 | - @mysterycommand 38 | - use-case for this RFC comes from sharing lambdas across multiple repos 39 | - right now have a tedious job to cd'ing around & only install prod deps 40 | - tried doing `npm install` + `npm shrinkwrap` + `npm ci` inside the lambda (ran into problems w/ local deps specified that eventually reach out to a registry to resolve vs. the local/bundled version) 41 | - @ljharb 42 | - have been saying this for awhile (in terms of ideal workspace layout on disk) 43 | - node_modules should live alongside the package.json for that part of the try (not hoisted) 44 | - peer dependencies/share dependencies could love somewhere else at the root (not hoisted) 45 | - @isaacs 46 | - we've potentially fixed this problem where workspaces respect lifecycle scripts that would allow you to set a `prepare` script to properly build/pack `b` 47 | - change to `npm-packlist` will go out soon (respects ignore scripts inside workspaces) 48 | - bundled dependencies should have their prepare/prepack scripts run 49 | - @ljharb 50 | - should all symlinked dependencies should have their prepare/prepack scripts run? 51 | - @isaacs 52 | - no, just define the dep as bundled as well as define it as a dependency 53 | - ex. 54 | ```json= 55 | { 56 | "name": "lambda-a", 57 | "dependencies": { 58 | "b": "file:../b" 59 | }, 60 | "bundleDependencies": [ 61 | "b" 62 | ], 63 | "scripts": { 64 | "prepare": "cd ../b; npm run prepare" 65 | } 66 | } 67 | ``` 68 | - **Actions:** 69 | - [ ] land npm-packlist in cli (@wraithgar) 70 | - [ ] RFC about running prepare scripts for linked bundled deps 71 | - [ ] RFC about workspace layout (ljharb) 72 | 73 | #### **Issue**: [#445 ⚠️ [RRFC] Breaking changes for `npm@8`](https://github.com/npm/rfcs/issues/445) - @nlf 74 | - @ljharb 75 | - upgrading more then one major at a time can be hard to do 76 | - if there's no major changes, it should be easy to backport 77 | - if there's easy changes, why not backport 78 | - @wraithgar 79 | - we are going to be better about this moving forward 80 | - this is a special case to drop node engines support 81 | - need to make a distinction between npm adding new features vs. node lts support 82 | - **Suport Policy**: https://github.com/npm/cli/wiki/Support-Policy 83 | - **Regression Reference**: `npm6 -> npm7 regressions` https://github.com/npm/statusboard/issues/397 84 | -------------------------------------------------------------------------------- /meetings/2020-01-08.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: January 8th, 2020 2 | # Open RFC Meeting (npm) 3 | 4 | ### Attendees: 5 | 6 | - Darcy Clarke (@darcyclarke) 7 | - Daniel Sauble (@djsauble) 8 | - Michael Perrotte (@mikemimik) 9 | - Ruy Adorno (@ruyadorno) 10 | - Claudia Hernández (@claudiahdz) 11 | - Wes Todd (@wesleytodd) 12 | - William Blankenship (@retrohacker) 13 | 14 | ### Agenda: 15 | 16 | - Housekeeping (introductions, outlining intentions & desired outcomes) 17 | - Issue: [FEATURE] prompt for module type as part of npm init 18 | - Issue: #48 [FEATURE] Expand the list of default ignored files 19 | - PR: #77 Quiet down or silence non-errors in npm install 20 | - PR: #76 rfc: Signed Packuments 21 | - PR: #46 fix: A files list should not exclude bundled dependencies 22 | - PR: #46 feat(git): add support for ::subdir in #committish 23 | - PR: #73 RFC for npm run to traverse directory tree up to the root before failing 24 | - PR: #71 RFC: Verified Account Linking 25 | - Issue: #70 Open RFC Meeting - Wednesday, November 27, 2019, 2:00 PM EST 26 | - PR: #68 RFC: Multiple Funding Sources 27 | 28 | ### Notes: 29 | 30 | - [2] https://github.com/npm/init-package-json 31 | - [2] We need to default to commonjs to continue functioning with the current version of ESM modules, that’s not up for debate. 32 | - [2] Instead of an issue, we need a PR so we can discuss the approach taken (e.g. prompt?) 33 | - [3] Need more eyeballs on this to create a more fully fleshed-out list of files to ignore during publishes. 34 | - [3] Need to analyze which packages would be impacted by these changes and communicate with the package maintainers. 35 | - [3] Would be nice to analyze the impact this will have on package sizes and general load on the registry. However, the primary goal is to help package maintainers avoid publishing files they didn’t intend to publish. 36 | - [3] Another issue is switching branches and accidentally publishing untracked files. Need to ensure the working directory is clean. 37 | - [3] Maybe have some sort of prompt which forces people to confirm before publish, which includes recommendations about potentially bad things in your working directory. 38 | - [3] This is likely to break a bunch of CI builds, so maybe put it behind an optional flag to start in npm@6. We can change the default behavior later. 39 | - [3] This is a breaking change so any change to defaults should be targeted at npm@7. 40 | - [3] Let’s document this practice of introducing breaking changes behind a flag before changing defaults. 41 | - [4] We don’t want to give a false sense of security if something failed that’s only evident from the log output. 42 | - [4] Could turn this into an issue or other comment that’s more fully fleshed out. 43 | - [4] Let’s update the description of this issue to better reflect the comments below (e.g. yarn and pnpm don’t actually have better output than npm). 44 | - [5] We would need to backlog this work if we take it on, since it involves registry-side changes, but otherwise seems like a very positive thing to do. 45 | - [5] Could add support to the CLI independently from the registry-side changes, to enable third-party registries could support this before we do. 46 | - [5] Also need to work side-by-side with simple mirroring solutions for npm packages to make sure the community will have what they need. 47 | - [5] Could add a check for this to `npm doctor` 48 | - [5] Needs to be done prior to install otherwise you could be p0wned before the validation runs. 49 | - [6] This may be handled by arborist in the future, Darcy will follow-up. 50 | - [11] This is ready to be implemented. 51 | - [11] This enables two approaches to sharing funding options. Either you can share a single link to a page that aggregates all your funding options, or just put all the different funding options in the package.json and have them show up on the CLI. 52 | -------------------------------------------------------------------------------- /meetings/2020-05-13.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: May 13th, 2020 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Claudia Hernández (@claudiahdz) 8 | - Ruy Adorno (@ruyadorno) 9 | - Wes Todd (@wesleytodd) 10 | - Kael Shipman (@kael-shipman) 11 | - Isaac Z. Schlueter (@isaacs) 12 | - Jordan Harband (@ljharb) 13 | 14 | ### Agenda 15 | 16 | 1. **Housekeeping** 17 | 1. Introduction(s) 18 | 1. Code of Conduct Acknowledgement 19 | 1. Outline Intentions & Desired Outcomes 20 | 1. Announcements 21 | 1. **Note:** [#136 We're Trying out Discussions for **RRFCs** & **cli** Questions](https://github.com/npm/rfcs/issues/136) 22 | 1. Feedback 23 | 2. Labelling/Automation 24 | 3. **PR**: [#135 Clarify/Outline the RFC Withdrawal Process & Amendment](https://github.com/npm/rfcs/pull/135) 25 | 4. **PR**: [#133 RFC: Remove --depth from npm outdated](https://github.com/npm/rfcs/pull/133) 26 | 5. **PR**: [#129 RFC: overrides](https://github.com/npm/rfcs/pull/129) 27 | 6. **PR**: [#126 RFC: Adding types information to the Package JSON in the registry](https://github.com/npm/rfcs/pull/126) 28 | 7. **PR**: [#121 Added proposal for package version `link#[version]` syntax](https://github.com/npm/rfcs/pull/121) 29 | 8. **PR**: [#117 RFC: npm workspaces - Running Commands](https://github.com/npm/rfcs/pull/117) 30 | 31 | 32 | ### Notes 33 | 34 | #### Announcements 35 | - Moved some of the issues into GitHub Discussions 36 | - Some small hiccups, discussions are missing labels, spamming issues participants 37 | 38 | #### Withdraw Process 39 | - Discussing how to un-ratify RFCs that are superceded or turn out to not be a good idea [#135](https://github.com/npm/rfcs/pull/135) 40 | - Even though a RFC is withdraw, its original problem should still be valid 41 | - Withdrawing a RFC should also involve a PR for discussion. 42 | - Proposed **Amendment Section** from the current [PR](https://github.com/npm/rfcs/pull/135) which can be added via PR in order to enable further discussion/documentation. 43 | 44 | #### Remove --depth from npm outdated 45 | - **Location** is going to be changed to point to its fs path 46 | - Overlap between `audit` and `outdated` in the sense both tackle the need to keep your modules up-to-date 47 | - Could use maybe a new workflow to address the same problem? 48 | - `ls` is problem in the same category, today `ls` prints the logical tree which obscures the actual fs tree 49 | - Worth exploring an `npm update` variation that also runs `audit` and fixes the problems 50 | - Ideally these never gets to be a problem that the user has to handle 51 | - Maybe repurpose `npm doctor` to do that 52 | - Kickstart the conversation around how do we display meaningful package trees in the cli. 53 | 54 | #### Overrides 55 | - From the last time we discussed these seemed to be the last remaining items: 56 | - First match is the only one which will affect the resolution 57 | - `'.'` member can not be an object 58 | - That should allow us to solve all the remaining problems surfaced 59 | 60 | #### Adding types info to registry 61 | - Simple Boolean might not be enough to solve that 62 | 63 | #### npm workspaces - Running command 64 | - Recap, workspaces install was ratified in an initial RFC 65 | - This RFC adresses the capability of running cli commands across all workspaces 66 | - Also, enable users to define a subset of workspaces in which to run a cli command 67 | - Action item: Create a poll in the current RFC to decide on what syntax to use for filtering 68 | 69 | #### Added proposal for package version link#[version] syntax 70 | - Some of this overlaps and can be solved by using `workspaces`, or `npm link` 71 | - How to make link deps work for a team (or more than just one person/machine) 72 | - Action item: Follow up with the discussion in the [PR](https://github.com/npm/rfcs/pull/121) 73 | -------------------------------------------------------------------------------- /meetings/2020-03-04.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: March 4th, 2020 2 | # Open RFC Meeting (npm) 3 | 4 | ### Attendees: 5 | 6 | - Darcy Clarke (@darcyclarke) 7 | - Michael Perrotte (@mikemimik) 8 | - Ruy Adorno (@ruyadorno) 9 | - Claudia Hernández (@claudiahdz) 10 | - Jordan Harband (@ljharb) 11 | - Wes Todd (@wesleytodd) 12 | - Isaac Z. Schlueter (@izs) 13 | 14 | ### Agenda: 15 | 16 | - Housekeeping (introductions, outlining intentions & desired outcomes) 17 | - Code of Conduct: https://www.npmjs.com/policies/conduct 18 | - Poll: https://github.com/npm/rfcs/issues/105 19 | - PR: #103 RFC: Add npm workspaces 20 | - PR: #96 RFC: Add publish confirmation prompt 21 | - Issue: #95 [RRFC] --save-peer flag 22 | - Issue: #93 [FEATURE] Standardised Browser-based Login Mechanism 23 | - PR: #92 RFC: Add staging workflow for CI and human interoperability 24 | - PR: #90 RFC: reduce lifecycle script environment size 25 | - PR: #76 rfc: Signed Packuments 26 | - Issue: #75 [FEATURE] prompt for module type as part of npm init 27 | - PR: #72 acceptDependencies package.json field 28 | - Issue: #513 [FEATURE] Support for monorepo dependency installations with NPM 29 | - Issue: #506 [BUG] npm audit places false blame 30 | - PR: #71 RFC: Verified Account Linking 31 | 32 | ### Notes: 33 | 34 | - [3] Skipped, in favor of meeting next Wednesday. 35 | - [4] Out of the agenda. 36 | - [4] The CLI is not aware if 2FA is enabled or not, we should take a look at this before going into discussion. 37 | - [4] Ruy will update the RFC. 38 | - [5] The recent workspaces/monorepo discussions have brought up the importance of making dependencies work together properly, hence improving how peerDependencies work 39 | - [5] We should have a flag to save dependencies as peer, the implementation is on arborist already. 40 | - [5] Isaac concerned on how we save dependencies. Should peer dependencies be associated to version ranges instead of a git deps? Logic is complicated. 41 | - [5] Agreed the CLI should just support `--save-peer` flag. 42 | - [5] More discussions have to be made around how we handle peerDependencies. 43 | - [6] Currently, standardizing shouldn't be hard to implement, we should prioritize this work on `npm-profile`. 44 | - [6] Need some final questions answered, a proper spec and it will be ready to be added to the backlog. 45 | - [7] Worth of a deep-dive session, a lot of unanswered questions on the issue. 46 | - [7] This feature has a lot of different use-cases that makes discussion harder. 47 | - [7] Allowing installing from a subdirectory in git, could solve _some_ of these use cases. 48 | - [7] https://github.com/npm/cli/issues/528 49 | - [7] https://github.com/npm/npm-package-arg/pull/46 50 | - [8] To be ratified. 51 | - [8] Conventions of names aren't changing. Package fields aren't normally used as environment variables either way. 52 | - [9] Currently blocked. Concerned about the overhead this will create during installation. 53 | - [9] npm has to queue up the work needed on infra. 54 | - [9] Can we move forward the CLI part of just fetching signatures and validating it, regardless of the infra implementation? 55 | - [9] A signature failure is like an integrity failure. 56 | - [9] Two downloads, instead of one (packument and signature). 57 | - [9] signed packuments vs signed versions? Modifications on which versions are available 58 | - [9] We have to outline the delta in threat models that signed packuments gets us, and signed tarballs doesn't. 59 | - [11] Feature has been implemented already in Arborist. Coming soon in v7. 60 | - [11] To be ratified. 61 | - [14] When transitive dependencies are out of date, there's no clear way to fix those up. 62 | - [14] npm update, only updates first-level deps and has a depth field. 63 | - [14] In v7, npm will update all your deps that are out of date in the tree. 64 | - [14] npm audit results can be changed in v7. 65 | - [14] Agreed we can change/improve UX on audit in v7. 66 | -------------------------------------------------------------------------------- /withdrawn/0009-package-overrides.md: -------------------------------------------------------------------------------- 1 | # Withdrawal Amendment 2 | 3 | Overridden by 4 | [0036-overrides](https://github.com/npm/rfcs/blob/latest/accepted/0036-overrides.md). 5 | 6 | ## Relevant Resources 7 | 8 | <https://github.com/npm/rfcs/pull/129> 9 | 10 | # Implement a package override option 11 | 12 | ## Summary 13 | 14 | Add a section to package.json that allows the user to designate packages as an 'override' or replacement at a particular version. 15 | 16 | ## Motivation 17 | 18 | In some situations, allowing more than one version of a package to be installed at the same time can cause unwanted behaviors. This will allow users to fix that by explicitly setting a single version to use. 19 | 20 | ## Detailed Explanation 21 | 22 | Users will be able to add an additional dependency section called 'replace' where they give a list of one or more packages to be installed at a specific version. Having this section will ensure that the only version of that package that is eventually installed to the project is the one set as an replacement. This will not affect the name, source, path, or other aspects of the package's installation. 23 | 24 | ## Rationale and Alternatives 25 | 26 | Users don't frequently need to do this sort of override/replacement because npm's nested tree structure allows for a collection of dependencies to require incompatible semvers for the same package. In many cases, the default behavior is acceptable and nothing further is needed. In other, more problematic situations, the user may encounter conflicting binaries or other components that cannot be used simultaneously. The only current options are to attempt to get the maintainers of the dependencies to make changes that will reduce these conflicts, or to use a tool like `https://www.npmjs.com/package/replace-deep-dep` to repair the requirements. 27 | 28 | ## Implementation 29 | 30 | In order to do this, the npm installer will need to read in an replacement section from `package.json`. This will have a simple format such as `replace: { 'foo': '1.2.3' }`. These values will need to be used at the end of the tree-building process to select the final version. It will be applied in a 'flat' way -- the same version will be selected for all sub-dependencies that require that package. 31 | 32 | Users will not be allowed to `npm publish` a package with this kind of dependency (we may choose to revise this behavior later). If someone installs a package that does have a 'replace' section, we'll warn them that this may have unexpected results. 33 | 34 | ## Prior Art 35 | 36 | - [Dart](https://www.dartlang.org/tools/pub/dependencies#dependency-overrides) uses a dependency override option that allows defining a specific source or version. 37 | - [Bower](https://github.com/bower/spec/blob/master/json.md#resolutions) has a setting for 'resolutions', which are package versions to fall back to if there's a conflict. 38 | - [Yarn](https://yarnpkg.com/en/docs/package-json#toc-resolutions) has a similar resolutions setting, which allows choosing a version or a file source. It allows a more complex system of selecting which packages the override will be applied to. 39 | 40 | Our goal in this RFC is to provide the simplest possible solution to a less common but impactful problem. The most important part of this feature is to define a safe fallback for package versions that conflict. 41 | 42 | ## Questions and Bikeshedding 43 | 44 | - Will a warning be sufficient if someone installs a package that contains an override in its own package.json? 45 | - Yes, that's fine. Or no warning is fine (just a verbose log or somesuch) 46 | - Do we want a `--force` option to allow publishing a package with this in place? 47 | - Yes. 48 | - Are there other workarounds users are likely to try, or edge cases to consider? 49 | - Not aside from replace-deep-dep. It's fairly tricky to do without it. 50 | - Should this be applied to devDependencies, optionally or by default? 51 | - Yes. By default. 52 | -------------------------------------------------------------------------------- /meetings/2020-12-02.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: December 2nd, 2020 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Ruy Adorno (@ruyadorno) 8 | - Christian Siebmanns (@christian24) 9 | - Nathan LaFreniere (@nlf) 10 | - Isaac Z. Schlueter (isaacs) 11 | - Bradley Farias (@bmeck) 12 | - Jordan Harband (@ljharb) 13 | 14 | ### Agenda 15 | 16 | 1. **Housekeeping** 17 | 1. Introduction(s) 18 | 1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct) 19 | 1. Announcements 20 | 1. **Issue**: [#287 [RRFC] Add nohoist option for workspaces](https://github.com/npm/rfcs/issues/287) - @socialwyze-franklin 21 | 1. **PR**: [#279 RFC for --default-command](https://github.com/npm/rfcs/pull/279) - @isaacs 22 | 1. **Issue**: [#275 [RRFC] `registry:<url>:<name>[@<version-range>]` dependency specifier](https://github.com/npm/rfcs/issues/275) - @isaacs 23 | 1. **PR**: [#273 RFC: npm workspaces - Config management](https://github.com/npm/rfcs/pull/273) - @ruyadorno 24 | 25 | ### Notes 26 | - Skipping next week OpenRFC call since we have GitHub Universe happening 27 | 28 | #### **Issue**: [#287 [RRFC] Add nohoist option for workspaces](https://github.com/npm/rfcs/issues/287) - @socialwyze-franklin 29 | - Queue up a deep-dive call to discuss this along with installation strategies, probably going to happen early January 30 | - @ljharb: hoisting might not be the ideal way to share dependencies across workspaces, we should come up with something better than that 31 | 32 | #### **PR**: [#279 RFC for --default-command](https://github.com/npm/rfcs/pull/279) - @isaacs 33 | - @ruyadorno: from @isaacs comment in the thread it seems improving `help-search` smarter sounds like the best solution until now 34 | - @christian24: `npr` bin is another possible avenue to help users that want a shorter/simpler `npm run-script` workflow 35 | - @darcyclarke: adding/maintaining a new binary might be extra work that we need to weigh 36 | - @isaacs: maybe we're trying to add something we don't necessarily want and/or need, let's backlog work on improving `help-search` and take the item out from the agenda and leave it there in case someone wants to chime in the future 37 | 38 | #### **Issue**: [#275 [RRFC] `registry:<url>:<name>[@<version-range>]` dependency specifier](https://github.com/npm/rfcs/issues/275) - @isaacs 39 | - @isaacs: replace second colon with a hash in the final implementation to simplify 40 | - @ruyadorno: we should also poke other package maintainers, Mael, Zoltan once the RFC PR is out 41 | - @isaacs: kinda extends aliases 42 | 43 | #### **PR**: [#273 RFC: npm workspaces - Config management](https://github.com/npm/rfcs/pull/273) - @ruyadorno 44 | - @christian24: maybe have a `npm workspaces init` to provide initial setup 45 | - @ruyadorno: The goal of the workspaces support is to suplement some of the functionalities provided by projects such as **Lerna** but we have no plans to work on some of its more complex features such as publishing workflows for example. 46 | 47 | #### [Experimental policies in Node.js](https://nodejs.org/api/policy.html) 48 | - @bmeck: Would like input from package managers, some categories of malware from the registry could be avoided by setting policies 49 | - @ljharb: You would need to opt-in to policies? 50 | - @bmeck: correct 51 | - @isaacs: having everything stop working in `npx` would be quite disruptive 52 | - @darcyclark: best neutral ground to bring over this discussion to bring over other package managers would be the [Node.js Package Maintenance Working Group](https://github.com/nodejs/package-maintenance/) 53 | - @darcyclarke: saw the "requested permissions" from the spec that would help out surface that information to users installing packages 54 | - @ljharb: It would be great to be able to tell what packages needs a given module (e.g: child_process), maybe using a npm top-level command (similar to how `npm fund` surfaces funding info) 55 | -------------------------------------------------------------------------------- /meetings/2022-02-23.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: February 23rd, 2022 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Ruy Adorno (@ruyadorno) 8 | - Jordan Harband (@ljharb) 9 | - Nathan Fritz (@fritzy) 10 | - Rick Markins (@rxmarbles) 11 | - Wes Garland (@wesgarland) 12 | - Owen Buckley (@thescientist13) 13 | 14 | ### Previously... 15 | 16 | - [2022-02-15](https://github.com/npm/rfcs/blob/main/meetings/2022-02-15.md) 17 | 18 | ### Agenda 19 | 20 | 1. **Housekeeping** 21 | 1. Introduction(s) 22 | 1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct) 23 | 1. Outline Intentions & Desired Outcomes 24 | 1. Announcements 25 | - [Taking March off from Open RFCs](https://github.com/npm/rfcs/issues/538) 26 | 1. **PR**: [#522 RFC: Option for npm diff to ignore cr at eol](https://github.com/npm/rfcs/pull/522) - @oBusk 27 | - @ruyadorno 28 | - want to ratify & move forward with this flag 29 | - open question is if we should make this the default behaivour? 30 | - author has already added this support to `js-diff` 31 | - @darcyclarke 32 | - what is the default `git diff` behaivour? 33 | - @ljharb 34 | - would be nice to shared config with `git` if we care about compliance/shared understanding/feature-set (ie. "mimic") 35 | - @wesgarland 36 | - we have the opportunity to be a bit more permissive 37 | - @ruyadorno 38 | - we should probably err on the side of safeness 39 | - like the idea from Jordan to possibly extend, read configs directly from git configs 40 | - @darcyclarke 41 | - Just worried that we might run into the types of problems we have with having both `.npmignore` and `.gitignore` to determine files on publishing 42 | - **Action:** 43 | - [ ] @ruyadorno to ratify 44 | 3. **PR**: [#519 RFC: Package Distributions](https://github.com/npm/rfcs/pull/519) - @darcyclarke 45 | - **Action:** 46 | - [ ] @daryclarke to set up meeting 47 | 4. **Issue**: [#482 [RRFC] npm should use stderr for errors](https://github.com/npm/rfcs/issues/482) - @exx8 48 | - @lukekarrys 49 | - had some concerns 50 | - this breaks the ability for output to be passed to other commands (ex. `--json` piping to `jq`) 51 | - feels weird to switch outouts based on `--json` flag 52 | - don't think we should print all errors to `stderr` 53 | - @ljharb 54 | - only quarentee I have with `--json` is that `stderr` is parseable `json` 55 | - can't expect the error path to give you a well-formed response 56 | - errors should not be considered parseable 57 | - difficult to guarentee 58 | - @lukekarrys 59 | - agree, but... 60 | - we can return `json` for errors that are recoverable (ex. registry errors) 61 | - don't want to make impossible the default `logevel` of `notice` 62 | - recommended path forward: 63 | - all log output go to `stdout` 64 | - all error output go to `stderr` 65 | - `--json` should always return `json` (in the recoverable scenarios) 66 | 67 | ### Other Discussion 68 | 69 | #### Global Command Usage 70 | - @fritzy 71 | - working on an issue where someone was told to use `npm audit` on a global package 72 | - we should remove 73 | - @ljharb 74 | - we should throw an error for cases when the command doesn't support it 75 | - **Action:** 76 | - [ ] remove messaging for audit during `npm install -g` 77 | - [ ] review `--global` usage for v9 78 | - [ ] `npm update` should have interactive mode & updating to latest version within range is important (ex. `npm update lodash@latest --save` saves back to `package.json` vs. `npm update lodash@latest --global`) 79 | 80 | #### [Issue: #4460 - Broken lockfile](https://github.com/npm/cli/issues/4460) 81 | - @fritzy 82 | - missing integrity values for old `package-lock.json` should warn &/or fix these 83 | - warning seems sensible 84 | - self-healing lockfile seems sensible 85 | - @ljharb 86 | - would want to know if the registry I'm configured against doesn't have integrity (ie. waring would be important) 87 | -------------------------------------------------------------------------------- /implemented/0010-monorepo-subdirectory-declaration.md: -------------------------------------------------------------------------------- 1 | # Monorepo subdirectory declaration 2 | 3 | **IMLPLEMENTED** by [#140](https://github.com/npm/cli/pull/140) and included in `npm@6.8.0`. 4 | 5 | ## Summary 6 | 7 | Add an optional `directory` field to the `repository` declaration a package makes in its `package.json`. If populated, use this directory to construct a more accurate link to the package's source code from its www.npmjs.com show page, and include it in the API response from registry.npmjs.org. 8 | 9 | ## Motivation 10 | 11 | Currently if a package is developed within a monorepo then npm has no knowledge of its location within that repo. That restricts the ability of npm or third party tools to provide helpful links to the package, or find its changelog. 12 | 13 | For example, the npm listing for [react-dom](https://www.npmjs.com/package/react-dom) links to the root ouf the [react monorepo](https://github.com/facebook/react), as does the [react-dom API response](http://registry.npmjs.org/react-dom). It would be preferable to link to the [sub-directory](https://github.com/facebook/react/tree/master/packages/react-dom) in which react-dom is developed. 14 | 15 | ## Detailed Explanation 16 | 17 | Package maintainers have the option to specify a `repository` object for their package, which takes `type` and `url` keys, or can be given a shorthand ([docs](https://docs.npmjs.com/files/package.json#repository)). The URL is intended to be passed directly to a version control system, so should not have directory details appended to it. 18 | 19 | I propose add an additional, optional `directory` key to the `repository` object, which allows maintainers who develop packages within a monorepo to specify where within the monorepo it lives. 20 | 21 | In the react-dom case, this would look like: 22 | 23 | ``` 24 | "repository": { 25 | "type": "git", 26 | "url": "https://github.com/facebook/react", 27 | "directory": "packages/react-dom" 28 | } 29 | ``` 30 | 31 | ## Rationale and Alternatives 32 | 33 | Alternative 1 is to maintain the status quo. It is not currently possible to accurately link to the source code of a package being developed within a monorepo, and this is not a disaster. Why change it? It would technically be possible to figure out the location of the package by crawling the repo in some way. 34 | 35 | Alternative 2 is to add the path details to the existing URL. 36 | 37 | Alternative 3 is for monorepo packages to specify the full repository URL, including directory, as their `homepage`. 38 | 39 | Alternative 1 isn't ideal because it makes it harder to build useful tools that take into account data in the package's repository. The best example is finding changelogs. 40 | 41 | Alternative 2 isn't ideal because in cases where npm couldn't reverse engineer the root of the repo it would cause issues fetching it with a VCS client. Adding a separate string that has to be combined with the repo URL has a better failure case (for packages hosted by a provider that npm doesn't know how to deal with the directory could simply be ignored). 42 | 43 | Alternative 3 isn't ideal because in cases where a monorepo has a non-repository homepage (such as React, which uses https://reactjs.org/), replacing it would leave no field for the monorepo's packages to specify that homepage. It also would not be clear that this is a field that is designed to be used by machines, rather than people. 44 | 45 | ## Implementation 46 | 47 | Update the `package.json` documentation in the https://github.com/npm/cli repo to give details of the new `directory` field of the `repository` declaration. 48 | 49 | ## Prior Art 50 | 51 | I'm not aware of any other tools that operate this way. Monorepos are particularly prevalent in the JS library development ecosystem. 52 | 53 | ## Unresolved Questions and Bikeshedding 54 | 55 | - Aside from serializing it on the package show view and in the API, what, if anything, does npm use the current `repository` information for? Could this RFC improve those processes? 56 | - Is there additional monorepo support work that this RFC can fit in to, or can it be approved on its own? 57 | -------------------------------------------------------------------------------- /meetings/2021-03-17.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: March 17th, 2021 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Ruy Adorno (@ruyadorno) 8 | - Isaac Z. Schlueter (@isaacs) 9 | - Gar (@wraithgar) 10 | - Jordan Harband (@ljharb) 11 | - Orta Therox (@orta) 12 | - Tierney Cyren (@bnb) 13 | - Saiansh 14 | 15 | ### Agenda 16 | 17 | 1. **Housekeeping** 18 | 1. Introduction(s) 19 | 1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct) 20 | 1. Outline Intentions & Desired Outcomes 21 | 1. Announcements 22 | 1. **PR**: [#332 RFC: Support Yarn style command/script/bin lookups from the CLI with npm prefix](https://github.com/npm/rfcs/pull/332) - @orta 23 | 1. **Issue**: [#325 [RRFC] Run preinstall / postinstall scripts on single package installation](https://github.com/npm/rfcs/issues/325) - @karlhorky 24 | 1. **Issue**: [#313 [RRFC] Add method for getting help on config option](https://github.com/npm/rfcs/issues/313) - @Yash-Singh1 25 | 1. **PR**: [#117 RFC: npm workspaces - Working with workspaces](https://github.com/npm/rfcs/pull/117) - @ruyadorno 26 | 1. **PR**: [#336 RFC: `where` config parameter](https://github.com/npm/rfcs/pull/336) - @nlf 27 | 1. **PR**: [#339 RFC: improving command suggestions](https://github.com/npm/rfcs/pull/339) - @nlf 28 | 29 | ### Notes 30 | 31 | #### **PR**: [#332 RFC: Support Yarn style command/script/bin lookups from the CLI with npm prefix](https://github.com/npm/rfcs/pull/332) - @orta 32 | - @wraithgar we're trying to improve the output/experience of `help`/`help-search` for when we fallback 33 | - @ruyadorno one question he has, "is there anything else we can do to help with the DX here?" 34 | - @ljharb ... 35 | - @isaacs currently, we have a short-coming because we don't have `npm exec-local` 36 | - @isaacs action: lets document the decision - We will improve the UX of running `npm tsc` in the presence of a locally-installed `tsc` bin and/or a defined `tsc` script in package.json, but we're _not_ going to do the thing requested in #332. 37 | 38 | #### **Issue**: [#325 [RRFC] Run preinstall / postinstall scripts on single package installation](https://github.com/npm/rfcs/issues/325) - @karlhorky 39 | - @isaacs need mutation events/lifecycle scripts for tree changes RFC 40 | - @wraithgar we should plan to move lifecycle scripts out of scripts... diffeent behaivours in different scenarios 41 | - @isaacs can bikeshed what the mutation event sends across when if fires the event (tree, or nothing... nothing is more future-proof) 42 | 43 | #### **Issue**: [#313 [RRFC] Add method for getting help on config option](https://github.com/npm/rfcs/issues/313) - @Yash-Singh1 44 | - @isaacs some bikeshedding... the current config refactor is going to unlock these ideas and this RRFC can probably become just an item in our backlog 45 | - @wraithgar refactoring work with config should help here 46 | 47 | #### **PR**: [#117 RFC: npm workspaces - Working with workspaces](https://github.com/npm/rfcs/pull/117) - @ruyadorno 48 | - @ruyadorno while making other npm commands to be workspace-aware, we're notcing that when you `cd` into a workspace, user's `npm` should detect that you're inside a workspace & run it the same way it would have been in the `root` and targetting that workspace, e.g: `npm test --workspace=./path` 49 | 50 | #### **PR**: [#336 RFC: `where` config parameter](https://github.com/npm/rfcs/pull/336) - @nlf 51 | - @isaacs the name is very vague 52 | - @wraigthgar just seems like we can bikeshed the name, `config-context` might be a more suitable alternative 53 | 54 | #### **PR**: [#339 RFC: improving command suggestions](https://github.com/npm/rfcs/pull/339) - @nlf 55 | 56 | #### Discussion: Better ERESOLVE output 57 | - ref. https://github.com/npm/rfcs/discussions/334 58 | - @isaacs let's make a block with more explicit looking npm commands along with the flags so that users can copy and paste 59 | - @isaacs one possible solution is to make these suggestions an interactive prompt so that users can be unblocked when hitting it (maybe same for the "did you mean" feature) 60 | 61 | #### Discussion: Configurable lockfile version 62 | - ref. https://github.com/npm/rfcs/discussions/316 63 | -------------------------------------------------------------------------------- /meetings/2022-01-26.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: January 26th, 2022 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Ruy Adorno (@ruyadorno) 8 | - Nathan Fritz (@fritzy) 9 | - Owen Buckley (@thescientist13) 10 | 11 | ### Previously... 12 | 13 | - [2022-01-19](https://github.com/npm/rfcs/blob/main/meetings/2022-01-19.md) 14 | 15 | ### Agenda 16 | 17 | 1. **Housekeeping** 18 | 1. Introduction(s) 19 | 1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct) 20 | 1. Outline Intentions & Desired Outcomes 21 | 1. Announcements 22 | - OpenJS World 2022 23 | - https://events.linuxfoundation.org/openjs-world/ 24 | - CFP: https://events.linuxfoundation.org/openjs-world/program/cfp/ 25 | 1. **PR**: [#516 RFC: Deprecated packages UX revamp](https://github.com/npm/rfcs/pull/516) - @ruyadorno 26 | - @ruyadorno 27 | - last step in cleaning up `npm install` output 28 | - this has been outstanding for quite a while 29 | - deprecation warnings can be consolidated (making them less scary) 30 | - suggest bubbling up this information in a different command like `npm ls`, `npm explain` or `npm outdated` 31 | - suggest scoping this under a command `npm deprecations` but not super attached to this 32 | - @fritzy 33 | - immediate thought, don't think we need a dedicated command or global flag 34 | - when something is installed global, we probably don't care about dev dependency 35 | - @darcyclarke 36 | - instead of removing the log messages, maybe just change the level of logging to something that would not be printed during a standard install 37 | - also add visual feedback to `npm outdated` 38 | - not sure about adding info to `npm explain`, if we were to do that we should pb augment explain output to add audit info, etc 39 | - @lukekarrys 40 | - maybe keep direct dependencies as warning logs during install? 41 | - security audits, deprecations and outdated seem to be very similar, what if there's a command that can surface all this info? 42 | - @darcyclarke 43 | - if we were to keep warning for direct dependencies why would we not have log warnings for audit reports for direct deps? 44 | - @ruyadorno 45 | - idea is to have a unified notifications system at the end instead 46 | - @darcyclarke 47 | - `npm ls` can also be a bit of a scope creep in the context of this RFC since you could also argue it can also be augmented to include audit issues and more 48 | - @ruyadorno 49 | - let's maybe reduce the scope to only notifications and a command to surface the deprecation messages 50 | - @darcyclarke 51 | - the command `npm deprecations`? just returns direct dependencies by default and accepts `--all` flag in order to show deprecations for transitive deps 52 | 3. **PR**: [#4260 feat(arborist)(reify): add an ability to add a hook](https://github.com/npm/cli/pull/4260) - @fritzy 53 | - @darcyclarke 54 | - During the npm7 rewrite the hooks feature was dropped 55 | - Maybe that wasn't as well publicized like other breaking changes such as peer dependencies 56 | - There's a current RFC to add new lifecycle events for arborist / npm installs 57 | 5. **Issue**: [#511 [RRFC] remove `npm-shrinkwrap.json` from the list of unignorable files](https://github.com/npm/rfcs/issues/511) - @ljharb 58 | - Update: need to action on the items from last week 59 | 6. **PR**: [#4227 Change the default save-prefix from ^ to none](https://github.com/npm/cli/pull/4227) - @zkldi 60 | - Update: need to action on the items from last week 61 | 7. **PR**: [#343 RFC: npm workspaces: auto switch context based on cwd](https://github.com/npm/rfcs/pull/343) - @ruyadorno 62 | - @ruyadorno 63 | - big gap between our current implementation & the way end-user's are expecting this feature to work 64 | - running a command within a directory that is apart of a workspace should be easier 65 | - we'll now walk up the require tree & determine if you're inside a workspace or not 66 | - @fritzy 67 | - PR that is open checks for if a workspace is defined at the root of the project 68 | - there's a way to opt-out from the behavior using `--no-workspaces` 69 | -------------------------------------------------------------------------------- /meetings/2020-07-22.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: July 22nd, 2020 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Christian Siebmanns (@christian24) 8 | - Ruy Adorno (@ruyadorno) 9 | - Isaac Z. Schlueter (@isaacs) 10 | - Claudia Hernández (@claudiahdz) 11 | - Lukas Spieß (@lumaxis) 12 | - Wes Todd (@wesleytodd) 13 | - Zbyszek Tenerowicz (@naugtur) 14 | 15 | ### Agenda 16 | 1. **Housekeeping** 17 | 1. Introduction(s) 18 | 1. Code of Conduct Acknowledgement 19 | 1. Outline Intentions & Desired Outcomes 20 | 1. Announcements 21 | 1. **PR**: [#165 RFC for parent package.json](https://github.com/npm/rfcs/pull/165) - @Christian24 22 | 1. **Issue**: [#160 [Poll] Preference on how to filter workspaces](https://github.com/npm/rfcs/issues/160) - @ruyadorno 23 | 1. **PR**: [#150 RFC: Add file+pack dependency protocol](https://github.com/npm/rfcs/pull/150) - @RecuencoJones 24 | 1. **PR**: [#129 RFC: overrides](https://github.com/npm/rfcs/pull/129) - @isaacs 25 | 1. **PR**: [#126 RFC: Adding types information to the Package JSON in the registry](https://github.com/npm/rfcs/pull/126) - @orta 26 | 1. **PR**: [#117 RFC: npm workspaces - Running Commands](https://github.com/npm/rfcs/pull/117) - @ruyadorno 27 | 1. **PR**: [#114 RFC: Expand list of ignored files](https://github.com/npm/rfcs/pull/114) - @ruyadorno 28 | 1. **PR**: [#96 RFC: Add publish confirmation prompt](https://github.com/npm/rfcs/pull/96) - @ruyadorno 29 | 1. **PR**: [#18 npm audit resolve](https://github.com/npm/rfcs/pull/18) - @naugtur 30 | 1. **PR**: [#185 Add ability to skip script hooks](https://github.com/npm/rfcs/pull/185) - @lumaxis 31 | 1. **PR**: [#182 RFC: npm audit licenses](https://github.com/npm/rfcs/pull/182) - @bnb 32 | 33 | ### Notes 34 | 35 | ### Parent package.json 36 | - Problem description: managing multiple packages, would be great to reuse info across these 37 | - might be a very difficult problem to solve due to the complexities of the JavaScript ecosystem 38 | - workspaces in npm7 could also open up more possibilities (maybe challenges?) 39 | - implementation ideas: 40 | - no package.json extension at install time 41 | - disallow publishing of extensions keys to the registry 42 | - [read-package-json](https://github.com/npm/read-package-json) / [read-package-json-fast](https://github.com/npm/read-package-json-fast) 43 | - add logic to merge package.json during pack tarball time 44 | - we could ship it in a v7-minor release 45 | - need research to land in the exact key to use in package.json 46 | - TS currently uses "extends" 47 | - if we allow users to extend from published versions in the registry it gets way harder to build the ideal install tree (might need to add read-package-json as a pacote dep, etc) 48 | - should it be a ref to published package or to a file? 49 | - limiting consumption to exclude git-specs already simplifies by a lot the surface for end consumers that would not have to deal how package authors publish tags, etc 50 | - def have some details to be figured out 51 | 52 | ### Preference on how to filter workspaces 53 | - Let's document the results in the RFC 54 | 55 | ### Add publish confirmation prompt 56 | - RFC ratified :+1: 57 | 58 | ### Audit resolve 59 | - @naugtur updated the RFC and updated JSON Schema 60 | 61 | ### Add ability to skip script hooks 62 | - Fix to strange behavior of `--ignore-scripts` in `npm run-script` 63 | - When running `npm test --ignore-scripts` it's more intuitive to skip `pretest` and `posttest` 64 | - Could it be tweaked to ignore specific lifecycle (e.g `postinstall`) when running `npm install`? 65 | - ref: https://npm.community/t/add-ignore-script-scripts/4169/18 66 | - That should be a diff RFC/discussion 67 | - RFC ratified :+1: 68 | 69 | ### npm audit licenses 70 | - license checker built into npm cli itself 71 | - command: `npm audit license` 72 | - might interact with the audit resolve proposal on how to block/ignore/allow results 73 | - should be part of the default `audit`, some niceties like having results at install time 74 | - missing a better control at level, since some of the problems might not have a solution, same as current `audit` implementation (are probably going to be better once audit resolve is available) 75 | -------------------------------------------------------------------------------- /meetings/2020-08-12.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: August 12th, 2020 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Ruy Adorno (@ruadorno) 7 | - Darcy Clarke (@darcyclarke) 8 | - Isaac Z. Schlueter (@isaacs) 9 | - Wes Todd (@wesleytodd) 10 | - Claudia Hernández (@claudiahdz) 11 | - Christian Siebmanns (@christian24) 12 | - Jordan Harband (@ljharb) 13 | - Zbigniew Tenerowicz (@naugtur) 14 | 15 | ### Agenda 16 | 1. **Housekeeping** 17 | 1. Introduction(s) 18 | 1. Code of Conduct Acknowledgement 19 | 1. Outline Intentions & Desired Outcomes 20 | 1. Announcements 21 | 1. **Issue**: [#190 [RRFC] npm run-series && npm run-parallel](https://github.com/npm/rfcs/issues/190) - @MylesBorins 22 | 1. **PR**: [#185 RFC: Add ability to skip script hooks](https://github.com/npm/rfcs/pull/185) - @lumaxis 23 | 1. **PR**: [#183 RFC-21: bring back subset of npm_package_* environs](https://github.com/npm/rfcs/pull/183) - @isaacs 24 | 1. **PR**: [#182 RFC: npm audit licenses](https://github.com/npm/rfcs/pull/182) - @bnb 25 | 1. **PR**: [#165 RFC for parent package.json](https://github.com/npm/rfcs/pull/165) - @Christian24 26 | 1. **PR**: [#129 RFC: overrides](https://github.com/npm/rfcs/pull/129) - @isaacs 27 | 1. **PR**: [#126 RFC: Adding types information to the Package JSON in the registry](https://github.com/npm/rfcs/pull/126) - @orta 28 | 1. **PR**: [#18 npm audit and audit-resolve.json](https://github.com/npm/rfcs/pull/18) - @naugtur 29 | 30 | ### Notes 31 | - npm 7 announcement 32 | - We'll be releasing versions throughout the coming weeks of the beta 33 | - Update notifications should ping you daily for npm@latest-7 34 | - #190 35 | - potentially split the proposal 36 | - questions on syntax/implementation 37 | - may want to split out functionality vs. strict `&&` functionality 38 | - running/chaining scripts is a common user/workflow 39 | - cross platform consistancy is often an issue when trying to accomplish this 40 | - concern: don't want to re`make` `make` 41 | - concern: want to make sure exit codes propagate properly 42 | - people would love to have globbing patterns supported 43 | - concern: globbing patterns 44 | - some people are using pre/post lifecycle scripts to try to accomplish this too 45 | - concern: this is a mindfield... 46 | - mixed: JSON syntax as a constraint on definition 47 | - idea: **travis** eqsque `yaml` file to define workflows 48 | - ask to follow up/add comments to RRFC thread 49 | - #185 50 | - want to move forward with this 51 | - v6 doesn't run anything /w `ignore-scripts`, v7 runs everything... need to fix this... 52 | - consensus to ratify (ie. lets merge & ship in the next beta release) 53 | - #183 54 | - name, version, config, engines, main, bin to be readded 55 | - can always fallback & read package.json yourself 56 | - question: `node -c` standard? 57 | - question: where is the line? 58 | - note: information that is contextual to a command should be provided (& should be the case in v7) 59 | - `exports`, `main` & others can be problematic 60 | - should be ratified since it's shipped this way in the v7 beta 61 | - #182 62 | - @darcyclarke to follow up with comments in the PR itself & ping @bnb 63 | - #165 64 | - thought is that, from the last call, that this was resolved already 65 | - believe that workspaces solves for this 66 | - concern: how to update outdated deps locally vs. from the parent 67 | - examples of how `parent` would be specified: `"parent": "typescript@1.2.3"` & `"parent": "local-thing@file:../local-thingie"` 68 | - note: implementation would look like pulling down the manifest from the defined `parent` then resolve deps based on what you may have also defined in your local `dependencies` 69 | - concern: many edges (ex. what do we do w/ `package-lock.json` & what is the developer experience for source control + sharing parents, circular parent references) 70 | - ask for comments to be added 71 | - #126 72 | - @orta is waiting on review of his PR from @isaacs 73 | - #18 74 | - note: we should do a Deep Dive call on the audit resolve proposal 75 | - good discussion was had yesterday during the Package Maintence WG call 76 | -------------------------------------------------------------------------------- /meetings/2022-08-10.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: August 10th, 2022 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Darcy Clarke (@darcyclarke) 7 | - Philip Harrison (@feelepxyz) 8 | - Nathan LaFreniere (@nlf) 9 | - Gar (@wraithgar) 10 | - Eddie Zaneski (@eddiezane) 11 | - Zach Steindler (@steiza) 12 | - Jordan Harband (@ljharb) 13 | - Brian DeHamer (@bdehamer) 14 | - Owen Buckley (@thescientist13) 15 | - Nathan Fritz (@fritzy) 16 | - Rick Markins (@rxmarbles)z 17 | 18 | ### Agenda 19 | 20 | 1. **Housekeeping** 21 | 1. Code of Conduct Acknowledgement 22 | 1. Outline Intentions & Desired Outcomes 23 | 1. Announcements 24 | 1. Introduction(s) 25 | 1. **PR**: [#593 Only Registry Dependencies](https://github.com/npm/rfcs/pull/593) - @thescientist13 26 | 1. **Issue**: [#622 [RRFC] include context that a module is overridden in npm ls](https://github.com/npm/rfcs/issues/622) - @bnb 27 | 1. **PR**: [#626 RFC for linking packages to their source and build](https://github.com/npm/rfcs/pull/626) - @feelepxyz 28 | 1. **PR**: [#23 Add Singleton Packages RFC.](https://github.com/npm/rfcs/pull/23) - @usergenic 29 | 30 | ### Notes 31 | 32 | #### **PR**: [#593 Only Registry Dependencies](https://github.com/npm/rfcs/pull/593) - @thescientist13 33 | - @thescientist13 34 | - investigating `npm query` 35 | - updated the RFC 36 | - @ljharb 37 | - would love for a `semver.npmjs.com`-esque experience 38 | - we should have `npm audit` be an umbrella command for all these types of types of checks 39 | - current defaults for `audit` are `"vulnerabilities"` & it's logging/type is `"warn"` 40 | - would be nice to not have to require a reified node modules to be able to use `npm query` 41 | - @feelepxyz 42 | - like this proposal 43 | - can this gate installation? 44 | 45 | #### **Issue**: [#622 [RRFC] include context that a module is overridden in npm ls](https://github.com/npm/rfcs/issues/622) - @bnb 46 | - @ljharb 47 | - `overrides` are not represented in `npm ls` or `npm explain` 48 | - @nlf 49 | - this is a bug 50 | - need to fix 51 | 52 | #### **PR**: [#626 RFC for linking packages to their source and build](https://github.com/npm/rfcs/pull/626) - @feelepxyz 53 | - @feelepxyz 54 | - introduces a new way to attest a source build is the origin of a package 55 | - prevents package hijacking attacks (ex. npm credentials are stolen, modifies the package & publishes to the registry) 56 | - linking doesn't actually prevent this 57 | - gating 2fa would help with preventing this as well 58 | - @ljharb 59 | - would be good to know what attack vectors this protects against that have *actually* been exploited? (as opposed to theoretical POCs that haven't actually been exploited) 60 | - maximally backfilling npm packages should be a high priority, especially ones without a build process 61 | - vs. annotating new packages 62 | - there's developer friction to publishing from CI 63 | - there's no way to compromise my personal 2fa today without compromising all of my credentials at once, which would defeat any automated approach that checks for authenticity. 64 | - @steiza 65 | - this is not a one size fits all security capability 66 | - @ljharb 67 | - concerned about creating perverse incentives do push the ecosystem in a direction 68 | - ex. typescript support/typescript badge being added to package pages on `npmjs.com` (maintainer doesn't have to include types, they can be submitted by the community to DT) 69 | - have been publishing from local machine for a decade, history proves this is trustworthy for most authors 70 | - could be harmful to the ecosystem/maintainers because it faults them for not publishing in this particular manner 71 | - is there a way we can "special-case adopt" existing/legacy publishes into this security/attestation so they aren't penalized 72 | - seems like there's other missing metadata about the linkage between packages & source repos 73 | - @steiza 74 | - we'll want to be careful about how we phrase this repo linking, e.g. careful not to show a verified check that penalises legacy packages 75 | - have not scoep this yet for legacy packages 76 | 77 | #### **PR**: [#23 Add Singleton Packages RFC.](https://github.com/npm/rfcs/pull/23) - @usergenic 78 | - ... 79 | -------------------------------------------------------------------------------- /meetings/2022-06-15.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: Wednesday, June 15, 2022 2 | 3 | # Open RFC Meeting (npm) 4 | 5 | ### Attendees 6 | - Nathan Fritz (@fritzy) 7 | - Jon Jensen (@jenseng) 8 | - Luke Karrys (@lukekarrys) 9 | - Owen Buckley (@thescientist13) 10 | - Gar (@wraithgar) 11 | - Evan Hahn (@EvanHahn) 12 | - Wes Todd (@wesleytodd) 13 | - 14 | 15 | ### Agenda 16 | 1. **Housekeeping** 17 | 1. Introduction(s) (ex. note the name of the call, state the week day & date) 18 | 1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct) 19 | 1. Outline Intentions & Desired Outcomes (ex. want to interact with the community to ensure that there is movement on important issues/ideas for the project) 20 | 1. Announcements 21 | 1. **Issue**: [#519 BREAKING CHANGE(engines): engines support for npm9](https://github.com/npm/statusboard/issues/519) - @lukekarrys 22 | 1. **PR**: [#5000 feat: add npm query cmd](https://github.com/npm/cli/pull/5000) - @ruyadorno 23 | 1. **PR**: [#595 Propose backwards-compatible improvements to compression](https://github.com/npm/rfcs/pull/595) - @EvanHahn 24 | 1. **PR**: [#593 Only Registry Tarballs](https://github.com/npm/rfcs/pull/593) - @thescientist13 25 | 1. **PR**: [#591 RFC: Registry-scoped keyfile / certfile credential options](https://github.com/npm/rfcs/pull/591) - @jenseng 26 | 1. **PR**: [#165 RFC for parent package.json](https://github.com/npm/rfcs/pull/165) - @Christian24 27 | 3. **Issue**: [#489 Initiative: `v8.x`](https://github.com/npm/statusboard/issues/489) - @darcyclarke 28 | 4. **Issue**: [#487 Initiative: `v10.x`](https://github.com/npm/statusboard/issues/487) - @darcyclarke 29 | 5. **PR**: [#564 RFC: Dependency Selector Syntax & `npm query`](https://github.com/npm/rfcs/pull/564) - @darcyclarke 30 | 6. **Issue**: [#443 Initiative: `v9.x`](https://github.com/npm/statusboard/issues/443) - @darcyclarke 31 | 32 | 33 | ### Notes 34 | 35 | 1. Enginges support for npm9 36 | - Gar: One issue is conflating support and compatability so we are looking to unwind that 37 | - Wes had a markdown file for a spec about this. npm can hopefully adhere to or contribute to this spec 38 | - Action item @lukekarrys: define support in a SUPPORT.md document in all of our repos 39 | - Action item @lukekarrys: read spec and figure out what portions of it we can/should adhere to 40 | - Action item @lukekarrys: look into how other tools use engines field in case there is differing behavior on warning/erroring for engines mismatch 41 | 1. PR: #595 Propose backwards-compatible improvements to compression - @EvanHahn 42 | - New compression algorithim zopfli other than gzip which shows a 5% improvement in initial tests 43 | - Concerns about a pure JS solution or a WASM solution on the cli being untenable 44 | - If it was in the language it would be a much easier decision 45 | - How is zopfli licensed? 46 | - Gar: we should look into whether this can solve the bug of machine specific integrity values 47 | - Higher level: does this make registry storage better? Or CPU time in aggregate? Can incentives be aligned to cut costs for registry/actions/etc? 48 | - This is currently only at publish time 49 | - Zopfli is Apache-2 licensed 50 | 1. PR: #593 Only Registry Tarballs - @thescientist13 51 | - Wes: Also wrote a tool for detecting git dependencies in lockfiles or trees 52 | - Is there an aggregate RFC for all the subcommands or actions that npm audit could run? 53 | - Compile a list of new audit features and come up with a high level foundation that would enable this RFC as well as other audit checks 54 | - How would this interface with `npm query`? npm query could be added after this RFC which would allow only a queryable subset of packages to be checked 55 | - eslint style rules which could implement this check as well as others. Action item @lukekarrys/@wesleytodd: this should be a new RFC 56 | 1. PR: #591 RFC: Registry-scoped keyfile / certfile credential options - @jenseng 57 | - Ready for implementation! Action item: @jenseng 58 | - Reach out to the npm team if you need assistance with implementation 59 | 1. PR: #165 RFC for parent package.json - @Christian24 60 | - Action items: review RFC since it has been stale for a few years 61 | -------------------------------------------------------------------------------- /meetings/2022-06-22.md: -------------------------------------------------------------------------------- 1 | #### Meeting from: June 22nd, 2022 2 | # Open RFC Meeting (npm) 3 | 4 | ### Attendees 5 | - Darcy Clarke (@darcyclarke) 6 | - Gar (@wraithgar) 7 | - Jordan Harband (@ljharb) 8 | - Owen Buckley (@thescientist13) 9 | - Nathan Fritz (@fritzy) 10 | - 11 | - 12 | - 13 | 14 | ### Agenda 15 | 16 | 1. **Housekeeping** 17 | 1. Introduction(s) 18 | 1. Code of Conduct Acknowledgement 19 | 1. Outline Intentions & Desired Outcomes 20 | 1. Announcements 21 | 1. **PR**: [#91 feat: feat(git): add support for :: in #committish](https://github.com/npm/npm-package-arg/pull/91) - @wraithgar 22 | 1. **Issue**: [#519 BREAKING CHANGE(engines): engines support for npm9](https://github.com/npm/statusboard/issues/519) - @lukekarrys 23 | 1. **PR**: [#5000 feat: add npm query cmd](https://github.com/npm/cli/pull/5000) - @ruyadorno 24 | 1. **PR**: [#595 Propose backwards-compatible improvements to compression](https://github.com/npm/rfcs/pull/595) - @EvanHahn 25 | 1. **PR**: [#593 Only Registry Tarballs](https://github.com/npm/rfcs/pull/593) - @thescientist13 26 | 1. **PR**: [#591 RFC: Registry-scoped keyfile / certfile credential options](https://github.com/npm/rfcs/pull/591) - @jenseng 27 | 1. **Issue**: [#489 Initiative: `v8.x`](https://github.com/npm/statusboard/issues/489) - @darcyclarke 28 | 1. **Issue**: [#487 Initiative: `v10.x`](https://github.com/npm/statusboard/issues/487) - @darcyclarke 29 | 1. **PR**: [#564 RFC: Dependency Selector Syntax & `npm query`](https://github.com/npm/rfcs/pull/564) - @darcyclarke 30 | 1. **Issue**: [#443 Initiative: `v9.x`](https://github.com/npm/statusboard/issues/443) - @darcyclarke 31 | 1. **PR**: [#165 RFC for parent package.json](https://github.com/npm/rfcs/pull/165) - @Christian24 32 | 33 | ### Notes 34 | 35 | #### **PR**: [#91 feat: feat(git): add support for :: in #committish](https://github.com/npm/npm-package-arg/pull/91) - @wraithgar 36 | - @wraithgar 37 | - this was an old item we never got to 38 | - allows for support of reference patsh in git repos (good for monorepos) 39 | 40 | #### **Issue**: [#519 BREAKING CHANGE(engines): engines support for npm9](https://github.com/npm/statusboard/issues/519) - @lukekarrys 41 | - @lukekarrys 42 | - want to reevalute our Node/engines support 43 | - odd versions seem like outliers to the current strategy 44 | - @wraithgar 45 | - difference between engines vs. support 46 | - engines is meant for "this should work in here" 47 | - @ljharb 48 | - should use @pkgjs/support create work 49 | - @darcyclarke 50 | - https://github.com/npm/cli/wiki/Support-Policy 51 | - Node needs to update their dependencies 52 | - we only "support" the latest version of `npm` 53 | 54 | #### **PR**: [#5000 feat: add npm query cmd](https://github.com/npm/cli/pull/5000) - @ruyadorno 55 | - @wraithgar 56 | - is taking over the work, will have updates by next week 57 | 58 | #### **PR**: [#595 Propose backwards-compatible improvements to compression](https://github.com/npm/rfcs/pull/595) - @EvanHahn 59 | - @fritzy 60 | - @EvanHan is still investigating this 61 | 62 | #### **PR**: [#593 Only Registry Tarballs](https://github.com/npm/rfcs/pull/593) - @thescientist13 63 | - @thescientist13 64 | - has made several updates from discussions/feedback (ref. https://github.com/npm/rfcs/pull/593#issuecomment-1160553640) 65 | - would like to discuss naming of flag again (ref. `--only-registry-deps` vs. current `--only-non-remote-deps`) 66 | - should we hold off until `npm query` is available? 67 | 68 | #### **PR**: [#591 RFC: Registry-scoped keyfile / certfile credential options](https://github.com/npm/rfcs/pull/591) - @jenseng 69 | - 70 | 71 | #### **Issue**: [#489 Initiative: `v8.x`](https://github.com/npm/statusboard/issues/489) - @darcyclarke 72 | - 73 | 74 | #### **Issue**: [#487 Initiative: `v10.x`](https://github.com/npm/statusboard/issues/487) - @darcyclarke 75 | - 76 | 77 | #### **PR**: [#564 RFC: Dependency Selector Syntax & `npm query`](https://github.com/npm/rfcs/pull/564) - @darcyclarke 78 | - 79 | 80 | 1. **Issue**: [#443 Initiative: `v9.x`](https://github.com/npm/statusboard/issues/443) - @darcyclarke 81 | 1. **PR**: [#165 RFC for parent package.json](https://github.com/npm/rfcs/pull/165) - @Christian24 82 | --------------------------------------------------------------------------------