System environment variables would get set with empty strings in development which breaks some builds. This fixes that by using the v2 of `/env/pull` introduced in https://github.com/vercel/api/pull/27777.
Migrating `vc alias` to use new argument parsing utilities.
Note that our snapshot tests show that our help text was out of sync with what we were actually parsing from the user.
In particular, we were showing `-n` as the shorthand for both `next` and `limit` and neither of these had this shortflag. `next` was parsing `-N` (capital), so I've updated it to that.
`--json` was parsed, but wasn't mentioned in the help text. I've kept it this way, but it may be worth adding a description. We may want to have a separate discussion about the nature and role of `json` output from our CLI as a whole.
This PR adds a rule to disallow the use of console.log/console.error/etc
from within the CLI package. The aim is to centralize our use of stdio
within the CLI so that everything moves through our client's output
module. It also disables the rule for all of the current console usage,
with the hopes that we will clean things up soon™
Also want to note that the rule only applies to usage from within the
CLI, so dependencies that the CLI pulls in (both external and even
within this monorepo) are unaffected.
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
In the past, we used the `VERCEL_ANALYTICS_ID` environment variable with the previous Speed Insights feature on Vercel to activate specific logic in Next.js, Nuxt and Gatsby for collecting and sending web vitals data.
With the new Speed Insights, that's not required anymore.
We no longer want to set the environment variable when detecting the new `@vercel/speed-insights` package.
This PR confirms that the variable is not set if the new package is detected.
The user's default team should be sorted to the top of the selector. This is a nice and simple way to do this, though I'm not sure how to test my changes -- would appreciate guidance!
Adds snapshot tests for the output from help as output by various commands. I expect to be changing some of the `Command` structs to continue the work started in [ [cli] Improve type signature of CommandOption #11394 ](https://github.com/vercel/vercel/pull/11394) especially as I build on work in [ Get flags specification #11433 ](https://github.com/vercel/vercel/pull/11433), and I want to be sure that the associated changes to help output are what we expect.
The way that we currently parse arguments throughout the vercel command line is through the `getArgs` function. This function takes three arguments: `argv`, `argOptions`, and `argsOptions`. (Those last two arguments are swapped in order from the real function). This is semantically muddy and likely to create mistakes. We have instances in our code base, such as `deploy/index.ts` which at the time of this pull request creates a variable named `argOptions` and passes it to the `argsOptions` argument of `getArgs`.
Further, the return type of `arg` the library we currently use to parse arguments is unclear as well. It puts positional arguments under an `_` key, instead of a meaningful name.
In this pull request, I create a function called `parseArguments` that takes the same three arguments as `getArgs` with improved names: `args`, `flags`, and `parserOptions`. It also changes the return type to be an object with two keys: `{args, flags}` allowing for clearer access patterns where the argument parser is used.
This introduces some additional capabilities on the `MockClient` and `MockStream` classes used in our unit tests.
The bulk of this code is copied over from https://github.com/SBoudrias/Inquirer.js/tree/master/packages/testing, but uses our existing stdin/stdout mocks instead of what's used there.
You can now use `client.getScreen()` to see the "last" screen pushed to stdin, which is super handy for snapshot tests. I've added a few as part of this PR, but many more can be written for our client output as well in the near future.
---
The `client.getScreen()` is also a handy debug tool, use it with `raw: true` to see a pretty printed output during tests:
https://github.com/vercel/vercel/assets/5414297/d0be6078-4901-4eb2-a6c9-1b51b576c1ba
---
This also adds an `events` object on the `MockClient` which allows us to write `client.events.keypress("down")` instead of the less readable `client.stdin.write('\x1B[B')` throughout our testing. This could also be moved to so that it's `client.stdin.keypress(...` or something similar. Note that I've only tested that this works in a login test, included in this PR. If we're happy to make this change I will make update the rest of the unit tests to use this syntax for the inputs.
Updates `@vercel/client` to always use the v13 create-deployment endpoint, even when `builds` is present. This allows for `projectSettings.nodeVersion` to be passed when `builds` is present.
Blocks preview deployments from being directly promoted. This relies on a new API version bump.
Copied the warning text from the UI:
This is a breaking change and will require a major version bump. Please don't merge until we're ready.
I did some pruning of old projects on my personal account last night, and accidentally broke CI. I've created a new tarball on the `curated-tests` team so that it doesn't happen again.
The only changes are from some slightly different punctuation and that typing 'y' or 'n' doesn't process the prompt, it now waits for "Enter". Easiest command to see this is an action is the `init`, if you provided an invalid example to initialize `vercel init astroz` and follow the prompts.
# Overview
Changing to `@inquirer/prompts` meant updating all existing usage of `inquirer.prompt`. This removed a lot of code since the `inquirer.prompt` function was extra verbose.
The user experience shouldn't have changed much besides different styling. `patch-inquirer` is incompatible with `@inquirer/prompts`. ~~We probably don't want to merge this until we have a new solution for styling.~~ The new default styling is preferred over our old styling.
There are lots of changes over many files, so I went back and organized the commit history. It will probably be easier to review this PR by commit.
## Tests
~~I had to change tests in ways that aren't great. Tests had a hard time recognizing output with escape codes in them, so I had to make the expected output more generic.~~ Using `strip-ansi` worked nicely to ignore styling changes in unit and integration tests.
I removed the unit test "should list projects running on an soon-to-be-deprecated Node.js version" because that test doing `jest.useFakeTimers().setSystemTime(new Date('2023-12-08'));` would make the "should remove a project" test fail. Really strange stuff! Couldn't think of a better solution than removing this, so looking for suggestions here.
This reverts commit 78e2c012f9.
This commit causes a failing test which contains the `zeroConfig: true`
field. It should have not been merged in the first place due to the
failing test, but Kodiak erroneously merged it before the tests were
passing.
When there are `builds` configuration, the v10 create-deployment
endpoint is used instead of the latest v13 endpoint. `projectSettings`
is not allowed in the v10 endpoint, therefore we can not send the
`nodeVersion` when `builds` project exists. Instead, we should look into
moving away from the v10 endpoint so that we can be using the latest
version of the endpoint for all deployments.
This unit test fails on my machine:
```
Expected: "pnpm i vercel@latest"
Received: "pnpm i -g vercel@latest"
```
This change allows the test to succeed on machines that need the `-g` flag.
Previously, we used `semver` which correctly identified the nodeVersion used in `package.json`, but failed in two cases:
1. If the specified `engines` range started too low, it wouldn't correctly identify a later version compatible with Vercel. (`">10"` was detecting as Node `"10.x"` not `"20.x"`)
2. If the specified `engines` version was fixed too low to be compatible with Vercel, we sent it, and then Vercel predictably errored. (`"10"` was detecting as Node `"10.x"` which would lead to an error in the build process)
Now, case 1 should properly use the latest node version. And case 2 will not send a node version override to the API and will print a warning to the user on the CLI, but the deployment will still proceed with the version specified for the project in the web interface.
We chose to keep the error message shown to the user consistent with what shows in the logs for the build container, that is:
> WARN! Node.js Version "10.x" is discontinued and must be upgraded. Please set "engines": { "node": "20.x" } in your `package.json` file to use Node.js 20.
### 🧐 What's in there?
Vercel's Speed Insights legacy injection is deprecated in favor of `@vercel/speed-insights` package.
CLI has a couple places where it warns users running `vc build` locally (or on their CI).
Some users complained about seeing the warning while they are already using the package.
This PR removes the message
### ❗ Note to reviewers
@tobiaslins, @timolins and I had a long discussion on the approach here.
This warning is issued because during `vc pull`, the project API on Vercel returns a legacy analytics.id field, [which is stored](https://github.com/vercel/vercel/blame/main/packages/cli/src/util/projects/project-settings.ts#L35) in `.vercel/project.json`.
While it is legit for users who never used `@vercel/speed-insights` package, it also appear for users who migrated from legacy.
Besides setting the warning, `VERCEL_ANALYTICS_ID` is set, which triggers auto-injection in Next.js, and is useful during self-hosting.
We first considered removing the legacy id from `project.json`, but it would break self-hosting.
We also considered printing the warning only if the application never used the package (which the project API on Vercel knows).
In the end, we realized that vercel.com Speed Insights dashboard has plenty of disclaimer and incentives to use the new package. Having it in the CLI doesn't worth the annoyance.
Read the package.json and use the `engines.node` value to set the
`projectSettings.nodeVersion` property on the create deployment API call
POST body. This allows for the Node 20 build container image to be
properly specified before the deployment is created on the server side.
I noticed that the framework version was not being printed on deployments in a monorepo. Turns out the framework detection logic was happening at the root of the monorepo, instead of the project directory.
- Removes all the legacy `flags`
- Renames the new `variants` to `flags`
Neither the legacy flags, nor the new variants were exposed to anyone, except for the type in build-utils, so there shouldn't be any issues removing/renaming them.
### 🧐 What's in there?
With the recent release of [`@vercel/speed-insights`](https://vercel.com/docs/speed-insights/package) own package (like [`@vercel/analytics`](https://vercel.com/docs/analytics/package)), it's time to encourage users to migrate.
With the availability of `@vercel/speed-insights`, users will have to opt-in explicitly by installing the package. Their benefit is a better and fine-grained control of the reporting (in particular, per-application sample rate).
### ❗ Note to reviewers
I used `console.warn` and hope it will stands out in the build logs. I'm happy to use anything else if you have better suggestions.
There's also a deprecation warning in Next.js, which covers a related but slightly different case, when users explicitly pass analyticsId in their configuration. https://github.com/vercel/next.js/pull/60677
Enables the symlink optimization that currently exists for `Lambda`
instances, but now for `EdgeFunction` instances as well. This will be
particularly beneficial for Remix applications which use edge functions
for many routes, since they will now all be represented by the same
underling function in production.
---------
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
Adds a `--deprecated` option to the `vc project ls` command that will only show projects currently running on a soon-to-be-deprecated Node.js version.
It also adds additional output providing more information to the user about what versions and a link to our documentation so they can learn more.
Example:
<img width="836" alt="Screenshot 2023-12-07 at 15 01 22" src="https://github.com/vercel/vercel/assets/16144158/3b7f7b13-802e-4af1-a76e-a158a477beb4">
Fixes a neat little bug with the intersection of northstar users, teams, and the behavior of `Array#find_index`:
When selecting an org for various cli actions _non_ northstar users will see a select list with their user in the 0th position, and their teams in the 1..nth positions, like so:
```
// user: Logan
// teams: [Avengers, X-Men]
○ Logan
○ Avengers
○ X-Men
```
We'd like to preselect either a team referenced in `client.config.currentTeam` or if said team cannot be found in the collection of a user's teams, preselect the user. So if `X-Men` is `currentTeam`, we find that item (element `1` in the teams array) and increment that value by `1` to account for the user being element `0` in the list of choices:
```
// currentTeam: X-Men
// user: Logan
// teams: [Avengers, X-Men]
○ Logan
○ Avengers
● X-Men
```
If we _can't_ find the `currentTeam` in the list of teams (or one isn't provided), `Array#find_index` returns `-1`, which we increment to by `1` to get the 0th element in the list of choices:
```
// currentTeam: undefined
// user: Logan
// teams: [Avengers, X-Men]
● Logan
○ Avengers
○ X-Men
```
Neat trick!
However, Northstar users _don't_ use the user account as the 0th element in the list of choices. Northstar users will in fact have a team that represents a hidden default team with the same name as their `user.name` and this will be the 0th element in their teams:
```
// user: Logan
// teams: [Logan, Avengers, X-Men]
○ Logan
○ Avengers
○ X-Men
```
This of course means the trick of `+1` to index of the team selects the wrong item _and_ can result in `undefined` in cases where the `currentTeam` references the last team.
```
// currentTeam: X-Men
// user: Logan
// teams: [Logan, Avengers, X-Men]
○ Logan
○ Avengers
○ X-Men
```
● how'd we get out here?!?! 👀
To address the issue this PR:
1. calls `findIndex` on the array of _choices_ checking for matches to `currentTeam`
2. wraps that in `Math.max` to set to `0` if `find_index` returns `-1` when a `currentTeam` can't be found.
Tracking down a bug with "northstar" users and have a little prefactor that
a) isolates setup code so it's less repeated
b) makes the "northstar" tests more reflective of actual execution.
Northstar users will always have a `currentTeam` value on their `client.config`:
aa0f3d712b/packages/cli/src/util/get-scope.ts (L18-L20)
And finally c) add tests for the case of a non-northstar users where a team scope is supplied.
The final hypothetical matching group (northstart users with team scope provided) is the bug that I'll fix with a refactor.
Some of our tests take quite some time to run and occasionally timeout when accessing https://yarnpkg.com/. We decided to make sure there is a lockfile for this _and_ just move over to `npm`. Shifting the `packages/cli` fixtures over in this PR.
I possibly missed one but I changed the install commands in tests and ran
* pnpm test
* pnpm test-unit
* pnpm test-dev
* pnpm test-e2e
During [project-level-rbac bug bash](https://linear.app/vercel/issue/IAM-1267/vc-certs-ls-fails-with-typeerror-for-contributors) we were facing a runtime error
```
Error: An unexpected error occurred in certs: TypeError: Cannot read properties of undefined (reading 'length')
```
The reason for that is because the API responded with `403`, which was expected in our test. However the CLI should not exit with a generic runtime error in this case.
This PR removes the `.catch(err => err)` error shallowing instruction.
During `vc build` do following when `@vercel/speed-insights` package is in dependencies:
- Show a warning when `VERCEL_ANALYTICS_ID` is set in environment variables
- Unset it in process.env to prevent auto-injecting old speed insights in Next.js
Durning `vc env pull` prevent pulling internal environment variables `VERCEL_ANALYTICS_ID`, `VERCEL_SPEED_INSIGHTS_ID` & `VERCEL_WEB_ANALYTICS_ID`. They are never required in the frontend
Restores DataDog flakey test detection. Briefly disabled because the old method of using exit codes would bail the entire workflow.
Taking the Turbo team's suggestion of looking at `runData.execution` values to avoid an extra loop. Now with unit tests!
Updates the `secrets` command to be a bit more modern. Initially I was going to covert this to typescript but that change was quite large, so going stepwise for easier review.
1. Moves the command implementation into a directory like other commands
2. Shifts the command data structure into its own file
3. Adds a test.
Other relevant comments inline.
`vc build` writes a file `.vercel/output/build.json` that contains the `argv` contents which could include sensitive information that needs to be sanitized.
Followup PR to #10090. Some of our commands duplicate global options into their `args` structure e.g. 2661f56347/packages/cli/src/commands/logs.ts (L25-L26)
Others commands omit it entirely.
This updates the `--help` output for commands migrated to our new structure (so far, only `deploy`) will show a "Global Options" section:
```
▲ vercel deploy [project-path] [options]
Deploy your project to Vercel. The `deploy` command is the default command for the Vercel CLI, and can be omitted (`vc deploy my-app` equals `vc my-app`).
Options
--archive Compress the deployment code into a file before uploading it
-b, --build-env <key=value> Specify environment variables during build-time (e.g. `-b KEY1=value1 -b KEY2=value2`)
-e, --env <key=value> Specify environment variables during run-time (e.g. `-e KEY1=value1 -e KEY2=value2`)
-f, --force Force a new deployment even if nothing has changed
-m, --meta <key=value> Specify metadata for the deployment (e.g. `-m KEY1=value1 -m KEY2=value2`)
--no-wait Don't wait for the deployment to finish
--prebuilt Use in combination with `vc build`. Deploy an existing build
--prod Create a production deployment
-p, --public Deployment is public (`/_src`) is exposed)
--regions Set default regions to enable the deployment on
--with-cache Retain build cache when using "--force"
-y, --yes Use default options to skip all prompts
Global Options
--cwd <DIR> Sets the current working directory for a single run of a command
-d, --debug Debug mode (default off)
-Q, --global-config <DIR> Path to the global ${'`.vercel`'} directory
-h, --help Output usage information
-A, --local-config <FILE> Path to the local `vercel.json` file
--no-color No color mode (default off)
-S, --scope Set a custom scope
-t, --token <TOKEN> Login token
-v, --version Output the version number
```
As commands are migrated to this new structure, they'll gain this output automatically.
Also adds a new `--environment=[preview|production]` filter and ability to pipe deployment URLs to `stdout`!
<img width="380" alt="image" src="https://github.com/vercel/vercel/assets/97262/20de0caa-2d63-4112-8213-cc15d23295c7">
```
vc list --environment preview
```
```
vc list --environment production
```
```
vc list --environment preview > preview_deployments.txt
```
