@automattic/vip 4.1.5 → 4.1.8

package/docs/EDGE-WORKERS.md

@@ -1,256 +0,0 @@
-# Edge workers
-
-This guide is the operator contract for scaffolding, validating, deploying, and managing VIP
-edge workers with VIP-CLI.
-
-## 1. Prerequisites and the inactive-create guarantee
-
-Use Node.js 22.19.0 or newer, npm 8 or newer, an authenticated VIP-CLI session, and access to the
-target application and environment. Start in a non-production environment.
-
-The Go CLI exposes the same commands under `vip-next edge-workers`. Local AssemblyScript
-builds still require Node.js and the project's npm dependencies; the Go CLI invokes the
-installed compiler directly. Use `--skip-build` only when the existing artifact has been
-separately reviewed against the intended source.
-
-The platform API creates every new worker with `active: false`; create does not accept an active
-input. The API also applies a database default of inactive as defense in depth. VIP-CLI relies on
-this enforced contract: deploy uploads a new worker first, confirms the returned inactive state,
-and enables it only when the operator explicitly passes `--enable`.
-
-## 2. Project layout and exact dependency versions
-
-`vip edge-workers init` creates the project root; `new` and `build` extend it with the per-worker
-and generated paths shown below:
-
-```text
-edge-workers/
-├── edge-workers.json
-├── package.json
-├── tsconfig.json
-├── lib/                       # optional shared modules
-├── build/                     # created by build
-└── workers/
-    └── <name>/
-        ├── worker.json
-        └── assembly/index.ts
-```
-
-`build/` is created when a worker is compiled and is ignored by Git. The generated direct
-dependencies are exact: `@automattic/vip-edge-workers-sdk` is `0.5.0` and `assemblyscript` is
-`0.27.0`. The starter exports only `alloc` and `on_client_response`; the other request phases are
-commented examples and are not active WASM exports.
-
-## 3. `edge-workers.json` schema
-
-The project descriptor selects the toolchain for every worker in the project:
-
-```json
-{
-	"type": "assemblyscript",
-	"sdk": "@automattic/vip-edge-workers-sdk@0.5.0"
-}
-```
-
-`type` is required and currently accepts only `assemblyscript`. `sdk` is optional metadata that
-records the generated SDK dependency. Workers are discovered from `workers/*/worker.json`; the
-project descriptor is not a worker registry.
-
-## 4. `worker.json` schema and location tri-state
-
-Each worker has its own manifest:
-
-```json
-{
-	"name": "security-headers",
-	"entry": "assembly/index.ts",
-	"location": {
-		"operator": "starts_with",
-		"value": "/api/"
-	},
-	"on_failure": "continue"
-}
-```
-
-- `name` is required, is unique within an environment, and must be a portable file name of at most
-  64 characters. Path separators, control characters, Windows-reserved names, `.` and `..`, and
-  trailing dots or spaces are rejected.
-- `entry` is required, must be relative, and must stay inside the worker directory.
-- `location` is optional. Its `operator` is `contains`, `equals`, `starts_with`, or `ends_with`, and
-  `value` must be a non-empty string.
-- `on_failure` is optional and is either `continue` or `error`.
-
-`location` has three distinct update states:
-
-| Manifest state  | Create                | Update                                              |
-| --------------- | --------------------- | --------------------------------------------------- |
-| Omitted         | Apply to all requests | Preserve the stored location                        |
-| `null`          | Apply to all requests | Clear the stored location and apply to all requests |
-| Location object | Store that location   | Replace the stored location                         |
-
-## 5. Safe scaffold workflow and the lockfile
-
-Initialize only an absent or empty target directory, install the pinned direct dependencies, and
-commit the npm lockfile:
-
-```sh
-vip edge-workers init
-cd edge-workers
-npm install
-git add package-lock.json
-git commit -m "build: lock edge-worker dependencies"
-vip edge-workers new security-headers --location starts_with:/api/
-```
-
-`new` validates the worker name and location before writing. Without `--location`, it reports that
-the worker applies to all requests and directs you to edit `worker.json` before deployment if that
-scope is too broad. A generated worker activates only the `client_response` phase. Implement and
-review that handler before activating any commented phase example.
-
-Use `--path <project>` with `new`, `build`, `validate`, or `deploy` when auto-discovery should not be
-used.
-
-## 6. Build and validation limits
-
-Build one worker with `vip edge-workers build <name>`. Both `vip edge-workers build` and
-`vip edge-workers build --all` build every discovered worker. Each successful line reports the
-relative `build/<name>.wasm` path and exact byte size. The build stops on the first compiler error;
-an empty project is an error.
-
-Validate against a non-production environment before deploying:
-
-```sh
-vip @example-app.develop edge-workers validate security-headers
-vip @example-app.develop edge-workers validate --all
-```
-
-Validation parses each selected worker manifest. A normal build also reads the project descriptor;
-then validation compiles the worker and sends the compiled WASM to the environment's server-side
-dry-run validator. It reports validity and detected phases. Validation does not execute requests
-and does not prove runtime behavior, performance, routing correctness, or application
-compatibility. `--skip-build` reads the existing `build/<name>.wasm`; it does not verify that the
-artifact matches the current source.
-
-## 7. Deployment plan fields and production confirmation
-
-Deploy prepares every selected worker before applying any remote mutation. Preparation reconciles
-the name as a create or update, builds or reads the artifact, validates it unless
-`--skip-validate` is passed, determines location and source behavior, and then prints a plan with:
-
-- `worker`, `action`, `current_active`, and `final_active`;
-- `current_scope` and `proposed_scope`;
-- `validation` and detected `phases`;
-- compiled `bytes`; and
-- `source` mode (`store`, `omit`, or `preserve`).
-
-Review the entire plan. A production deploy requires an interactive confirmation naming every
-worker, unless the operator deliberately passes `--skip-confirmation`. A worker name and `--all`
-cannot be combined. `--skip-build`, `--skip-validate`, and `--skip-confirmation` remove safety
-checks and should be used only when the omitted step has separate, current evidence.
-
-Deploy is upload-only by default. A newly created worker remains inactive, and an update to an
-inactive worker remains inactive. Pass `--enable` to enable a newly created or currently inactive
-worker after its upload succeeds. An update to an already-active worker stays active and skips the
-redundant enable request, even when `--enable` is present; the uploaded code and configuration
-therefore become live immediately. Disable an active worker first when the update must not become
-live on deployment.
-
-The plan and the single deployment confirmation cover both the upload and requested enable phase.
-For `--all`, every worker's planned final state is visible before any remote mutation begins.
-
-## 8. Source storage and `--skip-source`
-
-By default, deploy stores the worker's UTF-8 entry file alongside the WASM binary. It does not
-archive the full project or shared modules. `get` omits source by default; pass `--source` to make
-the additional on-demand source query and print the stored value.
-
-Source output preserves newlines and tabs, converts CRLF line endings to LF, and escapes other
-terminal control characters. This display formatting does not change the stored source.
-
-`--skip-source` means: do not store source on create; preserve stored source on update. Without
-the flag, an update replaces the stored source with the current entry file, including an empty
-file. The plan's `source` column shows the selected behavior before mutation.
-
-## 9. Enable, disable, delete, and rollback
-
-- `enable <name>` makes a deployed worker active. Production requires confirmation or the explicit
-  `--skip-confirmation` bypass.
-- `disable <name>` makes a deployed worker inactive.
-- `delete <name>` permanently removes a deployed worker. It prompts in every environment unless
-  `--force` is passed.
-
-There is no automatic rollback command and an `--all` failure is not rolled back. To recover,
-disable the affected worker first, inspect its current state, then deploy a reviewed known-good
-source/artifact or delete the worker if permanent removal is intended. Do not describe a redeploy
-as a rollback unless the exact prior source, manifest, dependencies, and compiled artifact are
-available and verified.
-
-If the enable phase of `deploy --enable` fails or times out, the worker's final active state is
-unknown. The command reports the last confirmed upload result and does not retry, roll back,
-disable, or delete the worker automatically. Use `edge-workers list` and `edge-workers get <name>`
-to verify the remote state before taking another action. Do not assume the worker remained
-inactive.
-
-## 10. `--all` and partial failures
-
-`build` with no name, `build --all`, `validate --all`, and `deploy --all` operate on workers in
-stable name order. Deploy preparation completes for all selected workers before remote writes
-begin, so a preparation or validation failure applies none of them.
-
-Application is sequential. Each worker's upload completes before its enable phase can begin. If a
-create or update fails, deployment stops immediately and reports the workers already applied, the
-failed worker, the workers not applied, and the original cause. If an enable fails, deployment
-reports that worker's confirmed upload state, treats its final active state as unknown, and stops
-before later workers. It does not retry, roll back, disable, or delete already-applied workers.
-Reconcile the reported names with `list` and `get` before retrying.
-
-## 11. Automation flags and `VIP_NON_INTERACTIVE=1`
-
-Automation should provide an explicit `@app.environment` alias (or equivalent app/environment
-options), an explicit worker name or `--all`, and `--path` when the working directory is not inside
-the project. Relevant bypasses are `--skip-build`, `--skip-validate`, `--skip-source`, and
-`--skip-confirmation` for deploy. Deploy also accepts `--enable`, which is an action request rather
-than a safety bypass and defaults to false. Validate accepts `--skip-build`; enable accepts
-`--skip-confirmation`; delete accepts `--force`. `list` supports the global `--format` output
-option. There is no edge-workers `--non-interactive` flag or other confirmation bypass.
-
-Set `VIP_NON_INTERACTIVE=1` to prevent interactive edge-worker production confirmation. In that
-mode, production `deploy` and `enable` fail closed unless `--skip-confirmation` is also supplied.
-The environment variable is not approval: the bypass flag must represent an explicit operator or
-pipeline authorization. Delete confirmation is independent; use `--force` only with equivalent
-authorization.
-
-## 12. Non-production manual lifecycle
-
-Exercise the complete lifecycle on a non-production environment first:
-
-```sh
-vip edge-workers init
-cd edge-workers
-npm install
-# Review and commit package-lock.json.
-vip edge-workers new security-headers --location starts_with:/api/
-# Implement and review workers/security-headers/assembly/index.ts.
-vip edge-workers build security-headers
-vip @example-app.develop edge-workers validate security-headers
-vip @example-app.develop edge-workers deploy security-headers
-vip @example-app.develop edge-workers list
-vip @example-app.develop edge-workers get security-headers --source
-vip @example-app.develop edge-workers enable security-headers
-# Send controlled requests and observe application behavior.
-vip @example-app.develop edge-workers disable security-headers
-# Update the source while inactive, then upload and explicitly enable after the upload.
-vip @example-app.develop edge-workers deploy security-headers --enable
-# An update while already active becomes live on upload and skips a redundant enable request.
-vip @example-app.develop edge-workers deploy security-headers --enable
-vip @example-app.develop edge-workers disable security-headers
-# Set location to null in worker.json and deploy to clear the stored location.
-# Omit location on a later update to preserve the stored location.
-# Confirm permanent deletion when prompted.
-vip @example-app.develop edge-workers delete security-headers
-```
-
-Before each enable, verify that the printed deployment plan matches the reviewed artifact, phases,
-scope, source mode, byte size, and final active state. If enable does not return a confirmed
-result, stop and verify with `list` and `get`; do not infer the final state. Promote to production
-only after the non-production lifecycle and a separate production change review succeed.

package/docs/GO-UPDATES.md

@@ -1,97 +0,0 @@
-# Updating the standalone Go CLI
-
-`vip-next` can check for and install newer 5.x releases from the
-[official GitHub releases](https://github.com/Automattic/vip-cli/releases).
-This feature is specific to the Go runtime; the Node CLI retains its npm
-update notifier.
-
-```sh
-vip-next update
-vip-next update --check
-vip-next update --channel preview
-vip-next update --channel stable
-```
-
-`update` authorizes installation without another prompt, including in
-non-interactive mode. `--check` reports availability without downloading or
-replacing executables. A successful check exits zero whether or not an update
-exists; a failed check or installation exits nonzero. Neither command needs a
-VIP login. Updates use the existing `VIP_PROXY` / `VIP_USE_SYSTEM_PROXY` policy.
-
-## Release channels
-
-Without an explicit preference, a prerelease installation follows newer
-previews through the stable release, then follows stable releases. Selecting
-`--channel preview` keeps following previews even after installing a stable
-release. `--channel stable` follows stable releases only. The preference is
-saved after a successful operation. Combining `--check --channel preview`
-changes that preference without installing binaries.
-
-Updates never downgrade. If the selected stable channel is behind an installed
-preview, the CLI waits for a newer stable release. Development builds, including
-`5.0.0-dev.<commit>`, must be replaced manually with an official release first.
-
-## Notifications
-
-Interactive invocations check at most once every 24 hours after a successful
-check. A request runs alongside the current command and has a five-second
-limit. The command never waits for that request at exit; very short commands
-may finish without refreshing the cache. There is no scheduled process.
-Completed failed checks back off for one hour and do not fail ordinary commands.
-
-Notices appear on interactive stderr. Automatic checks and notices are disabled
-in CI, tests, non-interactive use, JSON/CSV output, help/version, raw `wp`
-commands, and update commands. Set `VIP_NO_UPDATE_NOTIFIER=1` to disable automatic
-checks; explicit update commands still check immediately.
-
-The cache is under the operating system's user cache directory in `vip/update/`.
-The explicit channel preference is under the user configuration directory in
-`vip/update.json`. These files are separate from credentials.
-
-## Installation and recovery
-
-The updater downloads the matching archive and SHA-256 file, verifies them,
-and checks that the archive contains exactly the two executables for the target
-platform. If GitHub supplies an asset digest, that digest must match too.
-This trusts the official GitHub release over HTTPS; the checksums are not an
-independent publisher signature. Binary bytes, including existing code
-signatures, are preserved. The updater does not perform a separate native
-signer or notarization assessment.
-
-Both executables are staged before installation. Progress reports each step:
-
-```text
-Downloading 5.0.0-alpha.4… ✓
-Verifying download… ✓
-Updating vip-next… ✓
-Updating go-search-replace… ✓
-Updated to 5.0.0-alpha.4
-```
-
-The updater replaces the CLI and its bundled helper sequentially, retaining
-backups until both succeed. Ordinary failures attempt to restore the original
-files. If restoration fails, the error identifies the recovery record and backup
-paths. Inspect those paths and restore the original files or reinstall the
-complete release archive before retrying. The updater does not silently resume
-an incomplete update.
-
-This is not a crash-proof two-file transaction. Power loss or forced termination
-can require manual restoration, and another CLI process can observe the interval
-between replacements. Windows may retain the old loaded executable as a backup
-until a subsequent explicit update can remove it.
-
-The real CLI path is resolved through any entrypoint symlink. The bundled helper
-is selected from the executable directory's `bin/` subdirectory first, then from
-beside the CLI. PATH and `VIP_SEARCH_REPLACE_BIN` targets are never overwritten;
-an active override continues to control helper execution.
-
-Recognized package-managed installations receive package-manager instructions
-instead of file replacement. Installations created by the macOS `.pkg` or
-Windows `.msi` contain `.vip-next-installer.json` beside the binaries; keep this
-file intact. When an update is available, `vip-next update` directs these
-installations to the matching installer download. `--check` remains available.
-See [native installer installation and upgrades](BUILD-SIGNING.md#native-installers).
-
-Missing bundles, ambiguous layouts, and unwritable
-locations require manual installation. The updater does not elevate privileges.
-Supported release assets are macOS and Linux amd64/arm64, and Windows amd64.

package/docs/NPM-RELEASE-RECOVERY.md

@@ -1,47 +0,0 @@
-# Recover an interrupted stable npm release
-
-Use this when the stable publishing workflow created a GitHub release and tag,
-but failed before publishing that version to npm.
-
-1. Ensure the recovery workflow is merged into `trunk`.
-2. Open **Actions → Publish to npm (if applicable) → Run workflow**.
-3. Select branch **trunk**, set **release_mode** to **recover-stable**, and enter
-   the existing tag in **release_version** (for example, `4.1.2`).
-4. Leave **npm_tag** unchanged; stable recovery always publishes to `latest`.
-5. Select **Run workflow** and inspect the **Recover stable release** job.
-
-Do not rerun the original failed run to pick up workflow changes: reruns retain
-the original workflow. The original action also tries to recreate the existing
-GitHub release before it reaches npm publishing.
-
-Recovery builds and tests the existing tag, preserves the GitHub release, and
-uses the same workflow identity and `npm-publish` environment for npm trusted
-publishing. It enables npm error logging and refuses versions already published
-or older than the current `latest`. Successful publication starts the changelog
-and command-reference documentation jobs.
-
-Recovery does not create the next development-version PR that the regular
-publishing action normally opens after publication. Handle that version bump
-separately once recovery succeeds. If npm publication succeeds but a downstream
-documentation job fails, rerun only the failed jobs.
-
-## How the release artifact is prepared
-
-Stable releases, prereleases and recovery use the local
-[release tooling](../.github/scripts/npm-release/README.md) in this repository.
-No `vip-actions` changes are required. After building and testing, it runs the
-prepublish/pack preparation hooks in the source checkout and uses `rsync -a`
-without `-H` to copy into a fresh staging directory. This turns native dependency
-hard links into independent files without changing the source checkout's links. The workflow saves the current
-release tools before checking out an old tag, so that tag need not contain the
-new helper.
-
-The helper packs with lifecycle scripts disabled, validates the archive and runs
-`smoke:release` inside an extraction of that exact tarball. Validation rejects
-links and unsafe archive entries and verifies the package name/version. Both
-the dry run and real publication use the same validated `.tgz` with
-`--ignore-scripts`, so another build cannot recreate hard links after validation.
-
-For `4.1.2`, the Linux builds of bundled `cpu-features` and `ssh2` created three
-hard links that npm rejected with `E415: Hard link is not allowed`. Staging fixes
-the archive while preserving dependency bundling and the existing release tag.

package/docs/RELEASING.md

@@ -1,211 +0,0 @@
-# Releasing
-
-Please familiarize yourself with the [SETUP.md](SETUP.md) file before releasing.
-
-## New pull requests
-
-Follow these steps for new pull requests:
-
-1. Please note the publishing method (see [below](#releasing-a-new-version)).
-
-1. Ensure when you create your pull request that:
-
-   a. It merges to `trunk`. The release flow for VIP-CLI follows this pattern: **_feature branch -> `trunk` branch_**
-
-   b. The feature branch follows A8C branch naming conventions, e.g.: `add/health-query`, `fix/subsite-mutation`, etc.
-
-   c. The pull request code and description contain no sensitive information. Please do not include any internal links in PRs, changelogs, testing instructions, etc. as this is a public repository.
-
-   d. You have included changelog entry by adding a `## Changelog Description` section to the GitHub pull request description. All changelogs are posted to the [VIP Cloud Changelog P2](https://wpvipchangelog.wordpress.com/) which customers can view and follow.
-
-1. Once you've created your pull request, ensure that:
-
-   a. You have added [all the automated tests required](TESTING.md#automated-testing).
-
-   b. You have completed [manual testing of your change](TESTING.md#manual-testing).
-
-1. If updating a dependency (NPM package or Node), follow the [guidelines on updating dependencies](SETUP.md#updating-dependencies).
-
-1. Have your pull request reviewed by a colleague and approved — especially if it is a large change or a complex addition.
-
-1. Verify that your pull request passes all automated tests.
-
-1. Merge your pull request.
-
-## Preparing for release
-
-A few steps should be completed before releasing:
-
-1. Verify that [all relevant pull requests](https://github.com/Automattic/vip-cli/pulls) are merged.
-
-1. The [changelog](CHANGELOG.md) file in the repository should be [amended](#changelog-generation) to.
-
-1. Please note the publishing method (see [below](#releasing-a-new-version)).
-
-1. Determine strategy to [respond to problems post-deployment](#in-case-of-problems).
-
-1. The release has been tested across macOS, Windows, and Linux.
-
-1. All tests pass and your working directory is clean (we have pre-publish checks to catch this,
-   just-in-case).
-
-1. You have completed [final testing before deployment](TESTING.md#final-testing-before-releasing).
-
-1. The pre-publish [script](https://github.com/Automattic/vip-cli/blob/trunk/helpers/prepublishOnly.js) has been run. This script performs some confidence checks to avoid common mistakes.
-
-1. Finally, release your changes as a [new minor or major NPM version](#releasing-a-new-version).
-
-If you need to publish a security release, see [details below](#patching-old-releases).
-
-### Changelog generation
-
-Run the following to generate a changelog entry for CHANGELOG.md:
-
-```bash
-export LAST_RELEASE_DATE=2021-08-25T13:40:00+02
-gh pr list --search "is:merged sort:updated-desc closed:>$LAST_RELEASE_DATE" | sed -e 's/\s\+\S\+\tMERGED.*$//' -e 's/^/- #/'
-```
-
-## Releasing a new version
-
-You can release either using GitHub Actions or locally.
-
-### VIP CLI 5 Go prereleases
-
-VIP CLI 5 releases contain only the Go `vip-next` and `go-search-replace`
-binaries. The Node/npm CLI remains on 4.x and this workflow does not build or
-publish it.
-
-Before the first run, complete the
-[Buildkite prerelease promotion setup](BUILD-SIGNING.md#github-prerelease-promotion-setup).
-To publish a prerelease:
-
-1. Open the
-   [`Publish VIP Next prerelease` workflow](https://github.com/Automattic/vip-cli/actions/workflows/vip-next-prerelease.yml).
-2. Select `trunk` in the **Run workflow** branch selector.
-3. Enter an unprefixed version such as `5.0.0-beta.1`, then run the workflow.
-4. The workflow creates the tag at the selected full commit and creates a draft
-   release. The tag triggers Buildkite's native signing jobs.
-5. Wait while the workflow finds the Buildkite build with that exact tag and
-   commit, downloads all five archives, any available native installers, and their
-   checksums, validates the archive contents and installer containers, and
-   uploads the verified files. See [native installers](BUILD-SIGNING.md#native-installers).
-6. The release becomes public only after all verification and uploads succeed.
-
-If a run fails, its tag and draft release remain in place. Fix the cause and
-rerun the same version from the same commit. Never move the tag or reuse that
-version for another commit. The helper rejects a tag that resolves elsewhere
-and refuses to modify a published release.
-
-After publication, download the archive and checksum for one native platform,
-verify the checksum, and run the binary:
-
-```bash
-# macOS example
-test "$(shasum -a 256 vip-next-darwin-arm64.tar.gz | awk '{print $1}')" = \
-  "$(awk '{print $1}' vip-next-darwin-arm64.tar.gz.sha256)"
-tar -xzf vip-next-darwin-arm64.tar.gz
-./vip-next --version
-
-# Linux example
-test "$(sha256sum vip-next-linux-amd64.tar.gz | awk '{print $1}')" = \
-  "$(awk '{print $1}' vip-next-linux-amd64.tar.gz.sha256)"
-tar -xzf vip-next-linux-amd64.tar.gz
-./vip-next --version
-```
-
-The reported version must exactly match the prerelease tag. Windows users can
-verify with `Get-FileHash -Algorithm SHA256` before extracting and running
-`vip-next.exe --version`.
-
-### Publishing via GitHub Actions (preferred)
-
-This is the preferred method for pushing out the latest release. The workflow runs a bunch of validations, generates a build, bump versions + tags, pushes out to npm, and bumps to the next dev version.
-
-Please keep in mind internal guidelines before releasing.
-
-To release, follow these steps:
-
-1. Initiate the [release process here](https://github.com/Automattic/vip-cli/actions/workflows/npm-prepare-release.yml).
-1. On the right-hand side, select "Run Workflow".
-1. Pick your preferred version bump.
-1. Click `Run Workflow`.
-1. Wait for a pull request to appear. The pull request will update the version number and shall be assigned to you.
-1. When ready, merge the pull request. This will lead to a new version to be [published on npmjs.com](https://www.npmjs.com/package/@automattic/vip).
-1. Another pull request will be created to bump to a development version, also assigned to you. Merge it to finish the process.
-
-#### Versioning Guidelines
-
-- `patch`: for non-breaking changes/bugfixes and small updates.
-- `minor`: for some new features, bug fixes, and other non-breaking changes.
-- `major`: for breaking changes.
-
-#### Note on NPM token
-
-Publishing via the GitHub Action requires that the `NPM_TOKEN` be set correctly in GitHub Actions secrets. This should be an npm token generated for a bot user on [the npm @automattic org](https://www.npmjs.com/settings/automattic) that has publish access to this repo.
-
-### Alternative methods of releasing
-
-#### Publishing locally
-
-To publish locally, follow these steps:
-
-<summary><details>
-
-1. Create a pull request that adds the next version's changelog into `trunk`. Use the Changelog
-   Generate Hint above to generate the changelog, and refer to previous releases to ensure that your
-   format matches.
-1. Merge it after approval.
-1. Make sure `trunk` branch is up-to-date: `git pull`.
-1. Make sure to clean all of your repositories of extra files. Run a dangerous, destructive
-   command `git clean -xfd` to do so.
-1. Run `npm install`.
-1. Set the version (via `npm version minor` or `npm version major` or `npm version patch`)
-1. For most regular releases, this will be `npm version minor`.
-1. Push the tag to GitHub (`git push --tags`)
-1. Push the trunk branch `git push`
-1. Make sure you're part of the Automattic organization in npm
-1. Publish the release to npm (`npm publish --access public`) the script will do some extra checks (
-   node version, branch, etc) to ensure everything is correct. If all looks good, the new version
-   will be published and you can proceed.
-1. Edit [the release on GitHub](https://github.com/Automattic/vip-cli/releases) to include a description
-   of the changes and publish (this can just copy the details from the changelog).
-
-Once released, it's worth running `npm i -g @automattic/vip` to install / upgrade the released version to make sure everything looks good.
-
-</details></summary>
-
-#### Test Releases
-
-Sometimes, we want to release a version we can test before releasing it to the public. In order to that, we need to release it under a tag other than `latest`, usually `next`. By default, `npm` install from the `latest` tag, so if `@next` isn't specified explicitely in the installation command like `npm install @automattic/vip@next`, a user will not get this version.
-
-In order to do that, please follow this:
-
-<summary><details>
-
-1. Manually change the version in `package.json` and `package-lock.json` to a dev version. Example: `1.4.0-dev1`
-1. Run `npm publish --tag next` (When `--tag` is specified, we bypass the usual branch protection that doesn't allow you to publish form a brunch other than `trunk`).
-
-You can repeat this with every new version until you're happy with your version and ready to a public release. We currently don't support multiple branches for multiple versions. When it's the case, this process needs to be done for every version in every branch.
-
-</details></summary>
-
-#### Patching Old Releases
-
-There may be times when we need to push out a critical fix to the most recent release (or several past releases) such as for patching security issues or major bugs. This can be complicated by the fact that we may have some larger changes already merged into the `trunk` branch.
-
-<summary><details>
-
-For these cases:
-
-1. `git checkout` to the tag of the previous release.
-1. Apply the fix (either manually or by cherry-picking).
-1. Follow the release steps outlined above (as a `patch` release).
-
-Then, repeat for any additional versions that we need to patch.
-
-</details></summary>
-
-## In case of problems
-
-TODO: How to revert to a good state in case of problems?

package/docs/SECURITY.md

@@ -1,9 +0,0 @@
-# Security Policy
-
-> Although we strive to create the most secure products possible, we are not perfect. If you happen to find a security vulnerability in one of our services, we would appreciate letting us know and allowing us to respond before disclosing the issue publicly. We take security seriously, and we will try to review and reply to every legitimate security report personally within 24 hours.
-
-([Source](https://automattic.com/security/))
-
-## Reporting a Vulnerability
-
-For responsible disclosure of security issues and to be eligible for our bug bounty program, please submit security issuess via the HackerOne portal: https://hackerone.com/automattic