This PR attempts to balance the tests so they run concurrently and therefore faster.
I also sorted the tests so they are deterministic when splitting/chunking.
This PR:
- updates `packages/frameworks` to have most supported frameworks specify which dependency version should reflect the overall framework version
- updates `packages/fs-detectors` to allow framework detection that returns the full `Framework` record instead of just the slug
- updates `packages/next` to return the detected Next.js version in the build result
- updates `packages/cli` to leverage these changes so that `vc build` can add `framework: { version: string; }` to `config.json` output
The result is that Build Output API and supported frameworks will return their framework version in the build result of `vc build` when possible, which is used by the build container when creating the deployment. The dashboard later retrieves this value to display in richer deployment outputs.
Supports:
- https://github.com/vercel/api/pull/15601
- https://github.com/vercel/front/pull/18319
---
With the related build container updates, we get to see Next.js version in the build output. You'll see this with BOA+Prebuilt or a normal deploy:
<img width="1228" alt="Screen Shot 2022-12-09 at 2 48 12 PM" src="https://user-images.githubusercontent.com/41545/206793639-f9cd3bdf-b822-45dd-9564-95b94994271d.png">
---
### The Path to this PR
I went through all the supported frameworks and figured out how to best determine their versions. For most of them, we can check a known dependency's installed version number.
We can get most of the way only checking npm. For a handful, we'd have to support Go/Ruby/Rust/Whatever dependencies.
I started with a more complex method signature to allow for later expansion without changing the signature. It looked like this, in practice:
```
async getVersion(dependencies: DependencyMap) => depedencies['next']
```
However, after checking all currently supported frameworks, I don't think this will end up being necessary. It also has the constraint that all dependencies have to be gathered and presented to the function even though it only needs to check for one or two. That's not a huge deal if we have them already where we need them, but we don't. We could use a variant here where this function does its own lookups, but this seemed unnecessary and would beg for duplication and small variances that could cause bugs.
Further, if we only look at `package.json`, we're going to either see a specific version of a version range. To be precise, we have to look at the installed version of the package. That means checking one of the various types of lockfiles that can exist or poking into node_modules.
If we poke into node_modules to detect the installed version, we introduce another point where Yarn 3 (default mode) will not be supported. If we read lockfiles, we have to potentially parse `npm`, `pnpm`, and `yarn` lockfiles.
If we use `npm ls <package-name>`, that also fails in Yarn 3 (default mode). We could accept that and go forward anyway, which would look like:
```
const args = `ls ${packageName} --depth=0 --json`.split(' ');
const { stdout } = await execa('npm', args, { cwd });
const regex = new RegExp(String.raw`${packageName}@([\.\d]+)`);
const matches = stdout.match(regex);
if (matches) {
return matches[1];
}
```
But it turns out there's a `--json` option! That's what I ended up using, for now.
We could explore the lockfile route more, but after some initial digging, it' non-trivial. There are 3 main lockfiles we'd want to check for (npm, pnpm, and yarn) and there are different lockfile versions that put necessary data in different places. I looked for existing tools that parse this, but I didn't find any. We could certainly go down this path, but the effort doesn't seem worth it when `npm ls` gets us really close.
---
### Follow-up Versioning
Now that we know how to determine version per framework, we can vary configuration by version. In a future PR, we could allow a given value to vary by version number:
```
name: (version) => {
if (semver.gt(version, '9.8.7')) {
return 'some-framework-2''
}
return 'some-framework';
}
```
However, it may still be easier to differentiate significant versions by adding multiple entries in the list.
https://linear.app/vercel/issue/VCCLI-377/rollback-failing-for-enterprise-teams
When running `vc rollback` for a deployment belonging to another team, the command will fail requesting the rollback. Technically, the command should have failed trying to get the deployment. This PR checks that the current team matches the deployment being rolled back.
This PR also cleans up a bunch of deployment related things. There were 3 functions to get a deployment and now there's just one which uses the latest v13 API. Get deployment error handling now throws instead of returning an error. The `Deployment` type definition has been updated to match the v13 response and mock deployment data was also updated.
This PR generates lockfiles for the various monorepo build tests and updates the package versions to their latest within the major. This should help make these tests less flaky.
- Depends on https://github.com/vercel/nft/pull/297
- Fixes#7908
- Fixes#6194
This PR bumps `@vercel/nft` (for production) and `ts-node` (for
development) to fix ESM behavior.
Because Node.js cannot dynamically set [loader
hooks](https://nodejs.org/docs/latest-v18.x/api/esm.html#loaders) once a
process is started, I had to change the way `ts-node` is registered by
using environment variables such as `NODE_OPTIONS`. Most of the logic
for TS and ESM was pulled out of the child process and into the parent.
Co-authored-by: Ethan Arrowood <ethan.arrowood@vercel.com>
This adds a `link()` helper function to the `Output` class that is inspired by the `terminal-link` npm package.
The main difference with this version is that it's more tightly integrated with the `Output` class for the purposes of being able to toggle hyperlinks support on/off for [unit tests](4a54b19f46/packages/cli/test/unit/util/output/create-output.test.ts) by setting the `output.supportsHyperlink` boolean.
> **Note:** Since hyperlinks are still a relatively new feature, and users might not yet understand how to interact with them, we should only use this function for progressive enhancement scenarios at this time, and _not_ as part of a critical UX.
When adding an alias, the server can return a 400 Bad Request under these circumstances:
1. Invalid alias: no alias, empty string, null alias, alias domain is invalid, alias is not public, alias is not a subdomain (code: `'invalid_alias'`)
2. The deployment is indeed not ready (code `'deployment_not_ready'`)
3. The cert for the provided alias is not ready (code `'cert_missing'`)
4. There was an error assigning the alias (code varies)
`vc alias add` will treat all 4 of those bad request errors as the deployment "is not ready". Instead of treating all 400's as not ready, only return `DeploymentNotReady` if the `code` is set to `'deployment_not_ready'`.
Fixes flakey tests / CI:
- git metadata test for corrupted `.git` directory
- version identifier for `build-utils` being using in `fs-detectors`'s `devDependencies`
- bad import from `../dist/..`
### 📖 What's in there?
As part of Edge function GA, we're allowing `edge` as a runtime value.
This is adding to the allowed list, so we stay backward compatible.
[Linear ticket](https://linear.app/vercel/issue/EC-481/add-edge-to-the-list-of-allowed-runtimes)
I've kept one instance of `experimental-edge` in the test fixtures to ensure we still supports it.
### 📋 Checklist
#### 🧪 Tests
- [x] The code changed/added as part of this PR has been covered with tests
- [x] All tests pass locally with `yarn test-unit`
#### Code Review
- [x] This PR has a concise title and thorough description useful to a reviewer
- [x] Issue from task tracker has a link to this PR
### Related Issues
Allow the `ls` commands to have a `--limit` option that allows a user to fetch up to 100 records per page. Currently the default is 20, but the API allows up to 100. This keeps the default, if unspecified at 20.
Fixes: https://linear.app/vercel/issue/VCCLI-244/add-limit-option-all-the-ls-subcommands
This adds in `ls --limit` into:
- [x] `alias ls`
- [x] `certs ls`
- [x] `dns ls`
- [x] `domains ls`
I note that `env` has an `ls` command, but it doesn't have a pagination command and [looking at the API](https://vercel.com/docs/rest-api#endpoints/projects/retrieve-the-environment-variables-of-a-project-by-id-or-name) it doesn't support pagination or limit.
Wasn't sure if I should add in `-L` as a short cut to `--limit`, seems like a good idea.
~Couldn't find any tests that cover this API, but I could be looking in the wrong place, this is the first pull request, so my apologies if I've missed it. But I'll take another look tomorrow and leave it in the draft state for now.~
Added in unit tests for each of the commands and mocks for those unit tests, which is has caused this PR to get quite a bit larger, sorry about that.
Of note for reviewers, there were a few places where I changed `console.log` to `output.log` to get the output passed to the tests - as far as I can tell everything works on the command line and in tests.
### 📋 Checklist
#### Tests
- [x] The code changed/added as part of this PR has been covered with tests
- [x] All tests pass locally with `yarn test-unit`
#### Code Review
- [x] This PR has a concise title and thorough description useful to a reviewer
- [x] Issue from task tracker has a link to this PR
The `vc rollback` command provides the ability to redeploy a previous
deployment and check the status of a rollback request.
#### Requesting a rollback
vc rollback <id | url>
Upon requesting a rollback, the command will being a status polling loop
for 3 minutes. This timeout can be adjusted via the `--timeout <value>`
option which accepts time formats such as `30s` or `2m`. A timeout of
`0` (zero) will skip the status polling and immediately exit after
successfully requesting a rollback.
#### Querying rollback status
vc rollback
vc rollback status
The `status` action will return the most recent rollback info within the
last 3 minutes.
### Related Issues
>
https://linear.app/vercel/issue/HIT-117/cli-add-support-for-vc-rollback-deployid
>
https://linear.app/vercel/issue/HIT-118/cli-add-support-for-vc-rollback-[status]
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### Tests
- [ ] The code changed/added as part of this PR has been covered with
tests
- [ ] All tests pass locally with `yarn test-unit`
#### Code Review
- [ ] This PR has a concise title and thorough description useful to a
reviewer
- [ ] Issue from task tracker has a link to this PR
