If there is a monorepo that has one project at the root level we want to
return commands without the relative to root prefixes
---------
Co-authored-by: Chris Barber <chris.barber@vercel.com>
There are times when a request can arrive for a Python function with headers as a list. One of those examples is this header `x-vercel-proxied-for` which apparently is set twice. Example:
`[b'x-vercel-proxied-for', [b'207.81.134.243', b'172.71.147.74']]`
I took a quick scan through the other Python server implementations and I don't think any of them manipulate the value of the HTTP headers, the way the ASGI one does so I think we are good there.
To reproduce:
`curl https://..../ -H "foo: bar" -H "foo: bar"`
Will fail.
Fixes: https://github.com/vercel/vercel/issues/9132
Both `runtime: undefined` and `runtime: nodejs` have the same behavior
but we want to change that in the future.
The first step is to see if `runtime: nodejs` is currently used at all.
Instead of outputting a single SSR function at `/render` path, scan the
build manifest file to determine the proper paths to output the SSR
function at.
When Root Directory setting is used, and/or `vc build --output` is used,
do an intelligent "merge" (move) operation rather than copying the
contents of the build output directory to the destination. This should
overall be faster and avoid disk space issues for larger projects.
Instead of using `pathPrefix` from the Redux store, grab the value
directly from the "BuildArgs" passed to `onPostBuild()`. This value
seems to properly reflect whether or not `--prefix-path` mode was
enabled during the Gatsby build process.
We are getting reports of some larger Gatsby projects running out of
disk space during build which seem to be the result of copying the
static directory multiple times.
So move instead of copying, which doesn't fully solve the problem, but
it does kick the can down the road a bit. Very large projects would
probably still hit the disk limit at some point. Anyways, moving is
faster than copying so this is still a net positive.
The `.vercel/output` directory gets wiped away when `--output` is _not_ being used, but it should be deleted even when the flag is being used so that build scripts targeting Build Output API directly always start with a fresh slate.
1. `commandForIgnoringBuildStep` should be run at the project directory level not the monorepo root level
2. Simplifying the `installCommand` because doesn't need the relative root unless it is `npm`
Github Action for actions/cache has an issue that could cause it to take
1 hour and then timeout while trying to restore the cache.
Since `actions/setup-node` is no longer used to restore the pnpm cache,
the `timeout-minutes: 5` doesn't do anything for this action.
Instead we need to put an env variable on the `actions/cache` Github
Action to actually set the restore cache timeout.
```
env:
SEGMENT_DOWNLOAD_TIMEOUT_MINS: 5 # See https://github.com/actions/cache/issues/810
```
- See discussion here https://github.com/vercel/vercel/discussions/9340
- Related to actions/cache#810
- Follow up to #8639
Around 6 months ago, @styfle brought to my attention how `rename()` in build-utils used `reduce()` and could be written better. So, I rewrote it.
Before, the code would create a new `Files` object and copy the contents of the previous `Files` object. This caused heavy garbage collection and memory thrashing.
Instead, I created a single `Files` object, then add the files to it.
Results:
| # Files | Before | After |
|---|---|---|
| 1,000 | 75 ms | 1 ms |
| 10,000 | 10.6 s | 7 ms |
| 20,000 | 44.6 s | 16 ms |
| 30,000 | 105.5 s | 22 ms |
| 100,000 | Too long | 73 ms |
`.vercel/output` is already made fresh when running `vc build`, so the
plugin should not be doing this. In fact, it makes the `builds.json`
file be wiped away, which we don't want to happen.
Right now, static-build will add the necessary Gatsby plugins to the project's `package.json` at build-time, which has been bothersome for package managers when using a frozen lockfile.
Another issue with it is that we install `latest` version of the plugin, so the version used becomes disjointed from the CLI version itself, which leads to unpredictability when trying to debug issues or help users roll back to a previous behavior if something breaks.
So instead of patching `package.json` directly, include the plugins as deps of static-build itself, and create symlinks to those paths into the project's `node_modules` directory.
We currently don't make it obvious when `next export` is being leveraged which de-opts features like `middleware`, `rewrites`, `redirects`, etc. so this adds a notice to let users know when we are using `next export` output.
Adds some unit tests for the gatsby injection logic.
These are net new since we've heavily changed the injection logic. The tests and fixtures in `build-fixtures` and `builds.test.js` are seemingly not executed. We may delete those here too.
The `NODE_OPTIONS` env var value is wrong here and we shouldn't be overriding the user's setting to begin with.
Typically, it will be assigned in a build container or project settings.
We had Turborepo miscofigured. The `dependsOn: ["^build"]` means run all dependencies' build script, but it doesn't mean the package's build script will run first. For tests, it should always `dependsOn: ["build"]` (without the upcaret) instead to ensure its own build is complete before testing. I also learned that `outputs: []` can be dropped now since thats the default behavior.
We need to ensure that `@vercel/gatsby-plugin-vercel-builder` is executed as the very last plugin, which Gatsby itself doesn't really support in the plugins listing. So instead we'll patch the `gatsby-node` file to invoke the plugin in the project's own `onPostBuild()` hook, which does get executed last. The patching is similar to how is done with the `gatsby-config` file.
Astro v2 was released today. It includes [improved support for caching
all hashed build
assets](https://docs.astro.build/en/guides/upgrade-to/v2/#changed-_astro-folder-for-build-assets)
by gathering these all in a single `_astro` directory in build output
(previously these ended up in a number of different places).
This PR updates the Vercel frameworks config to provide out-of-the-box
immutable caching for these assets.
Co-authored-by: Steven <steven@ceriously.com>
Right now we create the SSR serverless function at path `_ssr`, and then symlink all the other pages to that function.
Instead just make the first page encountered be the "real" function, and symlink all the other pages to that endpoint.
Previously, the page-data Serverless Function and SSR Serverless Function were two distinct functions. They had almost identical file contents and just slightly different handler logic. So here we merge the handler logic into a single function and re-use the same Serverless Function for both page-data and SSR.
This simplifies the output quite a bit and deletes a good amount of code, and helps with build output size, cold boot times, etc.
So that the test runs get invalidated by Turbo when code changes within one of the plugin files. This is to avoid a PR breaking something in a plugin, but we don't notice it because the static-build tests still "pass" due to cache hit.
This function can sometimes give a TypeScript error if @types/node says 'code' should be a `number | null` and yet the code is returns as a `number`:
```
@vercel/build-utils:build: src/fs/run-user-scripts.ts(140,13): error TS2322: Type 'number \| null' is not assignable to type 'number'.
@vercel/build-utils:build: Type 'null' is not assignable to type 'number'.
```
I'm not sure if there are any other projects that depend on `@vercel/build-utils`, but it doesn't appear that the Vercel CLI nor the build container use this `execAsync()` function. If I'm mistaken, feel free to close this PR.
As this removal is a breaking change, setting the semver to major and not auto-merging unless others are in agreement.
Gridsome was not updated for [more than 2 years](https://www.npmjs.com/package/gridsome) and still relies on Webpack 4 what makes it incompatible with >= Node.js 17.
To make the example still deployable on Vercel, this adds an engine restriction to the `package.json` for that example.
Same as #9007.
* Sets a valid number of seconds for DSG expiration (10 minutes - do we want to make that configurable somehow?)
* Sets the `group` of DSG pages, so that the page-data and SSR pages are associated
* Outputs SSR/DSG pages with `/index.html` suffix so that those paths are accessible
* Updates SSR and page-data functions URL path parsing logic to handle querystrings and the `index.html` scenario
* Remove the unnecessary `rewrite` related to page-data URL paths
* Remove the page-data function static file fallback handling (they are accessible as just regular static files)
* Correct the path for the page-data endpoing when the root-level index page is SSR/DSG
Follow-up to https://github.com/vercel/vercel/pull/9258, even though that issue seemed to only happen when linked to the monorepo locally. In any case, this test will ensure those log messages are intact for any other change around that part of the codebase in the future.
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.
Instead of always including empty directories in `glob()`, make it an
opt-in behavior because technically it's a breaking change to include
them by default.
These were missing from the compiled ncc build of `helpers.ts`, and thus causing an error at runtime because the deps are not available within the Serverless Function.
The previous delay of 1500ms was causing some users to hit the API rate limits. This doesn't normally happen with a single deployment, but it can happen with several concurrent deployments (for example a monorepo with many projects).
We don't need to be polling so often, so this PR changed the polling delay to the following:
- During 0s-15s: check every 1 second
- During 15s-60s: check every 5 seconds
- During 1m-5m: check every 15 seconds
- During 5m-10m: check every 30 seconds
Update `@vercel/client` to send empty directory entries to the `POST` create deployment endpoint. This makes it so that CLI deployments will have empty directories re-populated in the build-container when doing `vc deploy`.
Follow-up to #9103.
In [a different PR](https://github.com/vercel/vercel/pull/9009), detecting frameworks by package name will also provide framework version metadata to the build. Should we update these framework detectors to look up their respective packages or were they not doing that already for a reason?
I left the old detectors in place as fallbacks, which looks like:
```
some: [
{
path: 'package.json',
matchContent:
'"(dev)?(d|D)ependencies":\\s*{[^}]*"remix":\\s*".+?"[^}]*}',
},
{
path: 'remix.config.js',
},
],
```
Please review carefully.
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.
Adds support for `remix.config.mjs` and `remix.config.cjs` and
also updates the example/fixtures to the latest version of Remix.
See: https://github.com/remix-run/remix/pull/3675
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.
Updates the `static-build` injector to use the new plugin.
Still need to verify somehow that the newly published plugin is working as expected. It should be fine since it was a copy-paste from the previous plugin repo, but always good to verify before we break everything!
This PR also updates the README in `@vercel/gatsby-plugin-vercel-analytics`
This PR migrates https://github.com/vercel/gatsby-plugin-vercel to this
repo so that we can eventually integrate into our monorepo tooling.
Since it currently requires Node.js v12 to be built, I've manually
built, copied, and committed the package as it exists now so that we can
publish a stable v1 of `@vercel/gatsby-plugin-vercel-analytics`.
After work completes on adding support for Gatsby v4, I will come back
to this package and update it to Node.js v16 so that it can be
integrated properly into the repository's tooling.
🚨 DO NOT SQUASH MERGE 🚨
Adds support for auto injection into Gatsby's new ESM config format. Only injects if the `gatsby-config.mjs` is present, and continues to default generation of `gatsby-config.js`
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.
Related issue: https://vercel.slack.com/archives/C017QMYC5FB/p1673025728939139
Updates the screenshot used for the Next.js template that shows up on the import/new project flow. The asset has been updated on Cloudinary (`/front/import/nextjs`) and this PR updates the version # of the url.
- 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>
When you are on this page, creating a project the image here is the screenshot of an example project in the `Vercel Examples` enterprise. However that was not working:
<img width="1060" alt="Screen Shot 2023-01-03 at 2 26 58 PM" src="https://user-images.githubusercontent.com/74699/210451850-8208f42b-de43-4ac4-a1fe-b90d88fe86d8.png">
It does this by hitting the API. In this case the problem is that there is a trailing slash on the domain name, causing the API to fail:
<img width="477" alt="Screen Shot 2023-01-03 at 2 29 48 PM" src="https://user-images.githubusercontent.com/74699/210452032-2e32ae61-df29-48b4-b79f-93f5bcf299d3.png">
So this removes that trailing, but I'll see if I can tighten this up as well so in the future it doesn't matter if there is a `/` there.
FYI: this passes unit tests in framework, because it passes the URL in demo through to `URL` and grabs the hostname, which strips out the `protocol` and trailing `/`. Perhaps we should do the same on front.
In July 2022, VitePress changed (https://github.com/vuejs/vitepress/pull/931) the output directory from `.vitepress/dist` to `docs/.vitepress/dist`, however the framework detector was still referencing the old .vitepress/dist` output directory.
There are some edge-case situations where a dependency or build process is expecting an empty directory to exist, and this expectation would fail currently because `glob()` does not return directory entries.
So update `glob()` to return entries for empty directories, which are also re-created properly when passed to the `download()` function.
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'`.
The CODEOWNERS file had an error referencing the `@vercel/edge-function` team, which does not exist. I assume this is supposed to be `@vercel/edge-compute`, but please confirm.
There are a [few edge-related teams](https://github.com/orgs/vercel/teams?query=edge).
### 🔖 What's in there?
Because Typescript's `libdom` does not have [`static Response.json()`](https://github.com/microsoft/TypeScript-DOM-lib-generator/issues/1444) (which modern browsers and edge runtimes are supporting), Typescript users can't use easily use it.
This helper fills the gap.
### 🧪 How to test?
It's covered with unit tests
🎉 Kit is live! 🎉
Merge prior to #9030. Manually updates Kit to latest (will need to have
a commit pushed after 1.0 goes live on NPM).
Co-authored-by: Steven <steven@ceriously.com>
According to AWS Lambda official documentation:
> The Lambda documentation, log messages, and console use the abbreviation MB (rather than MiB) to refer to 1024 KB.
https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html
This is also a convenient thing for us since CF Limits are in base-2 (even they are printed as base-10).
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 umi example currently uses `umi@2` which uses `webpack@4` under the hood to build.
Because of this issue https://github.com/webpack/webpack/issues/14532 Webpack@4 is no longer able to run on Node.js 17+.
Since we use [Node.js 18 as default](https://vercel.com/changelog/node-js-18-lts-is-now-available) for new projects, this example currently breaks when it gets deployed.
Temporary fix is here to ensure that a Node.js version below 17 is used in the meantime.
Augments the `BuildResultV2Typical` type to support `framework` and `frameworkVersion` for use in Richer Deployment Outputs.
I added this to a new `meta` object because it contains data about the result, not really part of the result.
---
Supports a related builder container update.
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
The default routes for Astro are redirecting all non-existing files to
`index.html`, which means that the `404.html` page is not used, and
instead `index.html` is shown for all not found pages.
Astro outputs files for each page (ie. `about.html`, `blog.html`, ...)
so the `{handle: 'filesystem'}` route should be enough to route all
existing pages correctly.
The missing part to ship this fix is to answer the following question:
can we safely assume that Astro will always output a `404.html` file?
Internal ref: https://github.com/vercel/customer-issues/issues/638
Co-authored-by: Okiki Ojo <okikio.dev@gmail.com>
Co-authored-by: Nathan Rajlich <n@n8.io>
Co-authored-by: Steven <steven@ceriously.com>
### Related Issues
Fixes: [slack
thread](https://vercel.slack.com/archives/C035J346QQL/p1669508061056179)
### 📋 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
### Related Issues
Fixes https://github.com/vercel/next.js/issues/43357
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### Tests
- [x] 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
Since introducing `vc build`, we no longer have isolated builds. This means we can share the cache across builds and improve TS compile across multiple builds.
For example, `api/foo.js` and `api/bar.js` are two different builds but they will likely share the same `tsconfig.json`. So this PR caches the initialization used before running the TS compiler so that it can be shared between builds of the same deployment.
In one customer build, we saw deployment time drop from 14 min to 7 min.
- Related to https://github.com/vercel/customer-issues/issues/925
### Related Issues
This fixes up a few links that had errors I found when scanning through
the code.
### 📋 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
`--cwd` is handled globally in the CLI entrypoint file, so if a relative path is used then it would be applied twice in `vc build` since it was _also_ handling `--cwd`. So remove `vc build`'s logic for it.
Fixes https://github.com/vercel/vercel/discussions/8948.
`json5` can be moved to a dev dependency since `ncc` bundles it into the output.
### 📋 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
- [x] 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
A simple update to the framework array, updating the blitz properties to
match the legacy framework. This PR detects a `blitz.config.(ts|js)`
file which is specific to the legacy framework. With the blitz 2.0
update the framework detection should automatically be next.js.
`pnpm` is our package manager of choice. This repository contains
framework starter templates, which check-in lockfiles to speed up clone
& deploy time. This PR updates a few frameworks to use `pnpm` instead of
`yarn` or `npm`.
- Updates Gatsby to Gatsby 5 given Node.js 18 support
- Updates to latest Nuxt 3 template for stable version
- Updates Astro to latest stable version, previously on RC
- Updates Angular to v15, previously on v13
Remove `--forceExit` and wait for the child `vc dev` process to close
before continuing.
Listen to the `'close'` event instead of `'exit'` to ensure stdio has
been flushed and closed before continuing.
Some tests cause `vc dev` to spawn child processes that in turn spawn
nested child processes that do not exit when the parent exits, so a
`nukeProcessTree()` helper was added to ensure all spawned processes are
cleaned up. Furthermore, some of the nested child processes don't
respond well to `SIGTERM` and we need to use `SIGKILL` if `SIGTERM`
doesn't do the job.
I uncovered a larger issue exposed by removing the `--forceExit` flag.
The go builder uses `go run` to build and run the go-based serverless
function. Turns out that `go run` will build the executable, then spawn
it with a parent process id (ppid) of `1` (launchd) on macOS. This means
that the go serverless function executable is not detected as a child
process of `vc dev` and won't be cleaned up, yet has inherited `stdout`
and `stderr` keeping Jest alive. The solution is to explicitly `go
build` the serverless executable, then run it.
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a
reviewer
- [ ] Issue from task tracker has a link to this PR
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
### Related Issues
Includes a guard checking for `vercel-build` and a LD flag to control
rollout.
### 📋 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
### Related Issues
Adds support for package.json based turbo configuration.
Includes test.
Confirmed with Turbo that `turbo.json` takes precedence over
`package.json` based config so that is how it is processed here.
### 📋 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
### Related Issues
No related issue, this is a drive-by fix
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] Issue from task tracker has a link to this PR
### Related Issues
A customer issue was raised that web-vitals analytics were not working for their Gatsby application, even though this is meant to be zero config.
It turns out the issue is due to their `gatsby-config` file being declared as a `ts` file, rather than `js`. This is perfectly valid and supported in Gatsby.
However, the static-build modifications that are made to automatically add the `gatsby-plugin-vercel` only apply to existing `js` files.
This lead to their deployments containing both a `js` and `ts` version of `gatsby-config`. Luckily, the `ts` version has higher precedence, so _only_ web-vitals were affected.
Closes https://linear.app/vercel/issue/FLA-364/investigate-gatsby-and-nuxt-data-issues
#### 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
Adds support for comments in JSON configs and skips operation when root directory is null or `'.'`
### 📋 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
The `readOutputStream()` module was counting "data" events, not lines specifically, and was failing for me locally. So that was removed, and updated the tests that were using it to use the `line-async-iterator` module instead to be more explicit and be able to perform assertions on a per-line basis.
### Related Issues
Improves how `vc build` handles monorepos. In short, this introduces
monorepo manager detection logic and then some helpful defaults so users
don't have to manually specify a `buildCommand` or `installCommand` when
linking a project within a monorepo.
### 📋 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
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
`runDevCommand()` assumes the dev command is an npm package and thus uses `npx` or `yarn run` to execute it. In the case of a Hugo-based app, there is no npm package, so we want spawn to find Hugo in the `PATH`. Then for Node-based apps, instead of `npx`, spawn should find the command since `node_modules/.bin` has been added to the `PATH`.
### Related Issues
> https://github.com/vercel/customer-issues/issues/871
Note: This PR is a recreation of https://github.com/vercel/vercel/pull/8864 because prettier changed a bunch of Hugo files, which was bloating the original PR.
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
On Windows, Python 3 is unable to listen on `0.0.0.0` and errors with:
```
[WinError 10049] The requested address is not valid in its context
```
The only solution I found is to bind to `127.0.0.1` or `localhost`. I've run into issues before with using `localhost`, so I chose to go with `127.0.0.1` and Windows (and macOS) seems to be happy.
### 📋 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
- [x] 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
We have a link to an error page here:
https://github.com/vercel/vercel/blob/main/packages/cli/src/commands/deploy/index.ts#L873,
however that page is currently a 404.
This is an attempt to explain the error a bit more. Because there are
many possible causes of a deployment error, this mostly focuses on
explaining how to get to the logs.
### Related Issues
Fixes https://github.com/vercel/vercel/issues/1732.
### 📋 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
Co-authored-by: Nathan Rajlich <n@n8.io>
Co-authored-by: Chris Barber <chris.barber@vercel.com>
### Related Issues
x-ref: [slack
thread](https://vercel.slack.com/archives/C01224Q5M99/p1667927545637489?thread_ts=1664536480.045539&cid=C01224Q5M99)
### 📋 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
### Related Issues
This ensures we properly route dynamic routes with segments in the
middle of the path for rsc paths and also ensures we normalize the
header values from the routes-manifest correctly.
x-ref: https://github.com/vercel/next.js/issues/42364
x-ref:
https://github.com/vercel/next.js/actions/runs/3415662540/jobs/5685787894
### 📋 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
### Related Issues
Required for https://github.com/vercel/next.js/pull/42482
### 📋 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
### Related Issues
Updates @types/node to the latest version within the v14 major (based on `npm view @types/node`)
```
❯ npm view @types/node@'>=14.0.0 <15.0.0' version | tail -1
@types/node@14.18.33 '14.18.33'
```
This PR also fixes the various necessary type changes
### 📋 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
### Related Issues
https://github.com/vercel/api/pull/15009 broke one of our integration tests. This PR fixes it.
### 📋 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
While working on #8742 i found some useful error checking code buried in
the CLI. This PR adds a new private package `@vercel/errors` that moves
those helpful utilities into its own package so it can be used
throughout the monorepo.
For Next.js apps, a custom `basePath` in the `next.config.js` file was being prepended to all paths except edge functions of which this PR resolves.
### Related Issues
> Fixes [#853](https://github.com/vercel/customer-issues/issues/853)
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
### Related Issues
Related - https://github.com/vercel/api/pull/15027
Removing setting the output directory placeholder - it is not extremely reliable https://vercel.slack.com/archives/C02HEJASXGD/p1667234137439189?thread_ts=1667232443.320769&cid=C02HEJASXGD
### 📋 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
Implements request headers override in middlewares.
#### New middleware headers
- `x-middleware-override-headers`: A comma separated list of *all* request header names. Headers not listed will be deleted.
- `x-middleware-request-<name>`: A new value for the header `<name>`.
### Related Issues
- #8724: Add helper functions for non-Next.js middlewares
- https://github.com/vercel/next.js/pull/41380: Next.js' implementation
### 📋 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
### Related Issues
x-ref: https://github.com/vercel/vercel/pull/8763
x-ref: [slack
thread](https://vercel.slack.com/archives/C035J346QQL/p1666645450798089)
### 📋 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
### Related Issues
x-ref: https://github.com/vercel/vercel/pull/8757
Fixes: [slack thread](https://vercel.slack.com/archives/C035J346QQL/p1666278547705429)
### 📋 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
### Related Issues
Copes with `socket hang up` errors.
I tested with https://github.com/Shopify/toxiproxy and set up a proxy that generated a socket hangup error. With a test URL etc it looks like this:
<img width="935" alt="Screen Shot 2022-10-21 at 2 13 48 PM" src="https://user-images.githubusercontent.com/74699/197289788-9467ebef-d4dd-4fae-bf41-f635b7857d03.png">
### 📋 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
- [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
We introduced a new endpoint: `/env/pull/:projectId/:target?/:gitBranch?` which will return a complete list of key/value pairs (environment variables) for the proper target environment, using the same logic as we use for deployments.
This means that we don't need to fetch env variables from multiple sources (system, project, shared) and stitch them on the client anymore.
- removes unused logic for fetching & merging environment variables on the CLI client
- offloads env variables generation to the API
- new: shared env variables are now supported in vc env pull!
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
<!--
Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change that you're making:
-->
This PR adds a feature in middleware to add, modify, or delete request
headers. This feature is quite useful to pass data from middleware to
Serverless/Edge API routes.
### New APIs
Adds a new option `request.headers` to the `MiddlewareResponseInit`
parameter in `NextResponse.next()` and `NextResponse.rewrite()`. It's a
[`Header`](https://developer.mozilla.org/en-US/docs/Web/API/Headers)
object holding *all* request headers. Specifically:
```ts
interface ExtraResponseInit extends ResponseInit {
request?: {
headers?: Headers
}
}
```
### Example
```ts
// api/hello.ts
export default (req, res) => {
const valueFromMiddleware = req.headers['x-hello-from-middleware']
return res.send(valueFromMiddleware)
}
// middleware.ts
import { next } from '@vercel/edge'
export default function middleware(request: NextRequest) {
// Clone request headers
const headers = new Headers(request.headers);
// Add a new request header
headers.set('x-hello-from-middleware', 'foo');
// Delete a request header from the client
headers.delete('x-from-client');
return next({
request: {
headers
}
});
}
```
### New middleware headers
- `x-middleware-override-headers`: A comma separated list of *all*
request header names. Headers not listed will be deleted.
- `x-middleware-request-<name>`: A new value for the header `<name>`.
### Related Issues
- Next.js' implementation: https://github.com/vercel/next.js/pull/41380
### 📋 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
Co-authored-by: Gal Schlezinger <gal@spitfire.co.il>
### Related Issues
x-ref: https://github.com/vercel/vercel/pull/8743
### 📋 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
### Related Issues
This will allow a shorthand form of `export const config = { regions:
'iad1' }`
### 📋 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
Co-authored-by: Damien Simonin Feugas <damien@vercel.com>
The `link` and `pull` commands have essentially duplicate code from `ensureLink()`. This
Card: https://linear.app/vercel/issue/VCCLI-224/adopt-ensurelink-across-commands
The `dev` command should also be updated to use `ensureLink()`, however that may interfere with this in progress PR: https://github.com/vercel/vercel/pull/8666.
### 📋 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
This allows `initialHeaders` and `initialStatus` for Prender as has been discussed quite a bit so that the proper headers can be applied when serving the fallback.
x-ref: [slack thread](https://vercel.slack.com/archives/C035J346QQL/p1666130102396799?thread_ts=1666122861.189349&cid=C035J346QQL)
x-ref: follow-up to https://github.com/vercel/vercel/pull/8737
x-ref: dd94dcab32/packages/next/src/server-build.ts (L970)
### 📋 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
When deploying a project that uses typescript, but typescript is not a dependency, the default typescript is used. The message that's logged when this happens says:
> Using TypeScript 4.3.4 (no local tsconfig.json)
which is not necessarily true. You can have a `tsconfig.json` file with no typescript dependency.
This message leads to bad debugging paths.
This PR updates the message to be more specific. Now the message will say:
> Using TypeScript 4.3.4 (no local "typescript" package detected)
### Related Issues
This ensures we probably route the `/` rsc route properly and adds a regression test along with enabling some now patched tests that were skipped.
Fixes: [slack thread](https://vercel.slack.com/archives/C043ANYDB24/p1665746921485109)
### 📋 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
- `meta.isDev` is unconditionally read after the first check (even though it could technically still be `null`, ignoring typescript)
- `meta.isDev` is explicitly asserted to be falsy, since the first `if` will return early if it's truthy, so the later checks are all redundant
- added `?.` for the `packageJson?.engines?.node` read
The rest is auto formatting (and if my local eslint warnings are correct then I'm just gonna close this PR...)
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
### Related Issues
This ensures we properly normalize the optional catch-all data route correctly with middleware as currently the route is expecting a repeated slash in the regex `(?:/(?` which it should just be `(?:(?`. This also adds a regression test for this specific case.
Fixes: [slack thread](https://vercel.slack.com/archives/C045FKE5P51/p1665153317613089)
### 📋 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
### 📋 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
### Related Issues
Otherwise you are not able to write a serverless function that returns a
Promise when using the ESLint rule
[@typescript-eslint/no-misused-promises](https://typescript-eslint.io/rules/no-misused-promises/)
Following function
```typescript
const handler: VercelApiHandler = async () => {};
```
will report a `Promise-returning function provided to variable where a
void return was expected`
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] Issue from task tracker has a link to this PR
### Related Issues
Add in placeholder settings for monorepos
### 📋 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
Fixes error:
```
ENOENT: no such file or directory, open 'querystring'
```
Unfortunately this issue would only manifest when installed externally. I.e. our tests didn't catch this since the `querystring` module is presumably present in the monorepo.
### Related Issues
This reduces the max length we check for when generating routes to ensure we stay under the 4096 limit after normalizing.
x-ref: https://github.com/vercel/customer-issues/issues/779
### 📋 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
### Related Issues
This ensures we handle the case were a lambda isn't present for `pages/404.js` with `getStaticProps` which can occur in older Next.js versions e.g. `v9.5.5`. This also adds a regression test for this specific version to ensure it is working as expected.
x-ref: https://github.com/vercel/vercel/pull/8663
Fixes: [slack thread](https://vercel.slack.com/archives/C03DQ3QFV7C/p1664945825621409)
### 📋 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
My IDE tells me `process` is unknown but mentions something about package.json so that may just be a superficial issue. I guess CI/CD will tell me soon enough.
This adds an env flag to override the file ref sema's so we can experiment with setting a higher sema.
One potential problem I'm seeing is that this is a generic sema for all the things that use this class. Not sure if that's going to work out as intended but in that case we'll have to find a different way :)
This removes the `styfle/cancel-workflow-action` in favor of native GitHub Actions `cancel-in-progress`.
The cancel key is workflow+branch but we don't want to cancel on the `main` branch.
https://docs.github.com/en/actions/using-jobs/using-concurrency
This moves an existing error from the build container to `vercel build`.
Its rare, but [Vercel Runtimes](https://vercel.com/docs/runtimes) might target a discontinued [AWS Lambda Runtime](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html) so we should fail fast when we know this has happened in `vercel build`.
A test has been added to demonstrate the failure using an old PHP version.
### Related Issues
Fixes: https://vercel.slack.com/archives/C03S8ED1DKM/p1664521958768189
### 📋 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
Here's the test for https://github.com/vercel/vercel/pull/8657.
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
When running `vc build` for a Next.js app, the Next builder will execute the server build which performs several steps. One of the steps is to trace each serverless function for any referenced files, then the raw list of files is scrubbed and filtered. The filtering uses OS specific file path comparisons to see if a file is of interest. Since it's comparing OS specific paths, we need to use OS specific path separators.
During testing on Windows, the traced serverless functions file list was always empty.
### 📋 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
- [x] 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
### Related Issues
x-ref: https://github.com/vercel/next.js/pull/40979
### 📋 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
When running `vc deploy` in a non-TTY context (i.e. CI), limit the number of progress updates to 25% increments (for a total of 5).
```
Uploading [--------------------] (0.0B/71.9MB)
Uploading [=====---------------] (18.0MB/71.9MB)
Uploading [==========----------] (36.0MB/71.9MB)
Uploading [===============-----] (54.0MB/71.9MB)
Uploading [====================] (71.9MB/71.9MB)
```
This avoids spamming the user logs with many progress updates.
### Related Issues
Parse `rush.json` files with `json5` because it is very common for these
to have comments in them
[Template for people to clone for
Rush](https://rushjs.io/pages/configs/rush_json/) which has comments in
it as a default which most people will clone
Docs of Rush showing to not use `JSON.parse`
https://rushjs.io/pages/help/faq/#why-do-rushs-json-config-files-contain--comments-that-github-shows-in-red
Added in tests with block comments and single line comments
### 📋 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
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
There was a case where the npm version wasn't decided base on Node.js version but instead based on the lockfile.
This PR fixes the case when a newer npm version is detected base on the lockfile.
- Follow up to #8598
- Follow up to #8550
### Related Issues
- Needs https://github.com/vercel/next.js/pull/40881 for this to be
useful
- Resolves EC-238
### 📋 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
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This PR refactor `doBuild()` to return `void`.
This will prevent accidental bugs like #8623 where an exit code number was returned instead of throwing on error.
We were doing this validation in `vercel dev` but not `vercel build`.
This PR adds `vercel.json` validation to `vercel build` too.
Note I am calling this a patch because invalid `vercel.json` was already failing when passed to the API so this allows a nice error message earlier in the process.
Add strict mode to `vc dev` edge function handlers. This is behind a flag in production, but that flag has been at 100% for a while. So, it seems safe to include it here unconditionally.
Also remove legal comments.
These changes bring `vc dev` edge function support closer to production.
This PR will make sure that CI fails fast if there is a network issue when restoring the cache.
This has been a known issue for 3 months and no resolution:
- https://github.com/actions/cache/issues/810
### Related Issues
Seeing this while deploying appDir to production. The collecting path is
not correct for generated dist from appDir
```
Collected static files (public/, static/, .next/static): 18.834ms
Error: ENOENT: no such file or directory, open '/vercel/path0/.next/server/pages/route-groups/checkout.html'
Error: An unexpected error occurred!
Error: ENOENT: no such file or directory, open '/vercel/path0/.next/server/pages/route-groups/checkout.html'
Error: Command "vercel build" exited with 1
```
Fix the deployment of SSG, the output html/json paths should be prefixed
with `/app`
Adding a TODO now for how to determine the app path route, leveraging
`.rsc` suffix in data route. Better to use app paths manifest to
refactor it later.
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] Issue from task tracker has a link to this PR
Co-authored-by: JJ Kasper <jj@jjsweb.site>
The `create-git-meta` file contains a `isDirty()` function which calls `git status` and subsequently causes one of the test fixture's git index to be updated. Turns out that `git status` will update/optimize the index in the background when invoked: https://git-scm.com/docs/git-status#_background_refresh.
By disabling this using the `--no-optional-locks` flag, `isDirty()` will no longer update the index when checking the status.
From my testing, the `--no-optional-locks` flag must be set after `git` and before `status`.
This PR is likely a better alternative to https://github.com/vercel/vercel/pull/8568 as this PR eliminates the problem all together.
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
This is to fix the issue with processing new entries of `potentialFiles` when there was a `readdir` cache hit
### Related Issues
Related to https://linear.app/vercel/issue/HIT-57/monorepo-detection-api-prevent-rate-limits
### 📋 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
The `disabledAt` and `enabledAt` properties need to be consulted in order to determine whether or not the Vercel Analytics feature has been enabled.
Related to https://github.com/vercel/vercel/discussions/8575.
Added a lock file to the normalize paths text fixture to speed up install dependencies.
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
### Related Issues
Add in getting the package paths for Rush workspaces.
First get the contents of the `rush.json` file. If the `projects`
property is an array, map through that array and return the
`projectFolder` as the package path.
### 📋 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
In this PR, we try to detect when npm install fails due to invalid peer deps and retry with `--legacy-peer-deps`.
This is a follow up to PR #8550 that explains more.
Steps to reproduce the npm bug:
```sh
corepack enable npm
echo '{"packageManager":"npm@8.5.5","dependencies":{"swr":"1.3.0","react":"16.8.0"}}' > package.json
npm install --legacy-peer-deps
npm install # works fine now that a lockfile exists
echo '{"packageManager":"npm@8.6.0","dependencies":{"swr":"1.3.0","react":"16.8.0"}}' > package.json
npm install # fails with code ERESOLVE (Conflicting peer dependency)
```
Windows doesn't like it when the env has both a `PATH` and a `Path`, so `cloneEnv()` must remove `Path` after copying it to `PATH`.
Renamed the next builder `01-normalize-routes` test to `01-normalize-paths` as it's test normalization of output paths, then re-enabled the test for Windows.
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
This is a (further 😄) continuation of #8379 by @theMosaad, so that the tests can run.
I also added a change to make `images` _not_ be sent to the create deployment API endpoint, since it fails validation there.
### Related Issues
Add in Rush workspace
### 📋 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
Follow up to #7874 since the remote cache was not used on `main`.
We can unconditionally set these env vars with the latest turbo so it will work for contributors too.
### Related Issues
Fixes:
https://github.com/vercel/vercel/actions/runs/3086450305/jobs/4990850756
### 📋 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
### Related Issues
Updates our test fixture for related changes in latest canary of
Next.js.
Fixes: https://vercel.slack.com/archives/CGU8HUTUH/p1663607276817069
### 📋 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
Use posix path separators for routes (static pages, lambdas, etc) instead of the native platform path separator (e.g. backslash on Windows).
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
Prior to `npm@8.6.0`, running `npm install --legacy-peer-deps` to generate a lock file and then later running `npm install` would work fine.
After `npm@8.6.0`, running `npm install` with that same lock file will fail with `code ERESOLVE` and `Conflicting peer dependency`.
Steps to reproduce:
```sh
corepack enable npm
echo '{"packageManager":"npm@8.5.5","dependencies":{"next":"12.3.0","react":"16.8.0"}}' > package.json
npm install --legacy-peer-deps
npm install # works
echo '{"packageManager":"npm@8.6.0","dependencies":{"next":"12.3.0","react":"16.8.0"}}' > package.json
npm install # fails with code ERESOLVE
```
This PR introduces a flag so we can safely upgrade npm to a newer version without breaking thousands of deployments.
The [npm docs](https://docs.npmjs.com/cli/v8/using-npm/config#legacy-peer-deps) say the flag is not recommended so we also make sure that once we upgrade to Node.js 18, we stop flagging `--legacy-peer-deps` because its safe to introduce breaking changes.
On Windows 10 and 11 machines, environment variables are not case sensitive. The system PATH is actually defined as `process.env.Path`, however Node.js kindly handles the case sensitivity and will automatically return the system path when specifying `process.env.PATH`.
When we clone the environment variables via `{ ...process.env }`, we lose the automatic resolving of `Path` to `PATH`. To fix this, we need to explicitly copy the `PATH`.
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
### Related Issues
https://nx.dev/more-concepts/folder-structure#integrated-repo-folder-structure
Nx monorepo has an option to use Nx workspaces.
Nx workspace is defined within the root `workspace.json` file
Within this `workspace.json` file the workspace packages are under
projects
```{
"$schema": "./node_modules/nx/schemas/workspace-schema.json",
"version": 2,
"projects": {
"myblog": "apps/myblog",
"svelte-app": "apps/svelte-app",
}
}
```
Within `getNxWorkspacePackagePaths` get the projects object values for
the paths
Nx is listed as the last workspace manager within
`workspace-managers.ts` because other workspace managers could exist to
check for before Nx workspaces because the `workspace.json` could exist
but not be the correct workspace manager
Nx workspace file can exist when yarn/npm workspaces exist. When this
happens, the workspace.json file is empty with no projects so it will
not add any package paths to the list to look through for projects.
### 📋 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
Path segment previously were not working when a `go.mod` file is present. This was fixed likely by https://github.com/vercel/vercel/pull/8291, so now this PR is just a test to ensure this case stays working.
Covers:
- Importing a built-in Builder with `@latest` should use the CLI's version
- Importing a built-in Builder with `@canary` should use the CLI's version
- Importing a built-in Builder with an explicit version should install to `.vercel/builders`
Update "typescript" and add a `yarn.lock` file.
It started failing without the lockfile with compilation issues:
```
$ react-scripts build
Creating an optimized production build...
Failed to compile.
/vercel/path1/node_modules/@types/react-router/index.d.ts
TypeScript error in /vercel/path1/node_modules/@types/react-router/index.d.ts(149,100):
Type expected. TS1110
147 | ): match<Params> | null;
148 |
> 149 | export type ExtractRouteOptionalParam<T extends string, U = string | number | boolean> = T extends `${infer Param}?`
| ^
150 | ? { [k in Param]?: U }
151 | : T extends `${infer Param}*`
152 | ? { [k in Param]?: U }
error Command failed with exit code 1.
```
This makes `vc dev` utilize the same Builder installing and importing logic that `vc build` uses. So now the Builders will be installed locally on a per-project basis, rather than being installed to a shared global installation directory.
Instead of replacing "127.0.0.1" in `vc dev`, replace "0.0.0.0" when rendering the URL to access the `vc dev` server.
The thought here is that the IPv6 form is replacing the catch-all host name (`::`), but the IPv4 version is only replacing the explicit "127.0.0.1" version, so there's an inconsistency.
Considering the catch-all host names are not usually intended to be routable anyways, we will fix the inconsistency by only replacing the catch-all versions instead of localhost.
Also, since Node.js will default to binding to the catch-all address when not explicitly specifying a host, this replacement will only happen in that case. If the user is explicitly specifing a host to bind to (i.e. `vc dev -l 127.0.0.1:8080` or `vc dev -l tcp://[::1]:8080`) then it makes more sense to print explicitly what the user specified.
This PR fixes an issue when the sha begins with `0` and causes [an error](https://vercel.com/vercel/vercel/EP7fVcXKsoodzWRy3fwG8AoeQcs6) when looking up the tarball:
> Error: ENOENT: no such file or directory,
> copyfile '/vercel/path0/packages/build-utils/vercel-build-utils-v5.4.2-0251253.tgz'
> -> '/vercel/path0/public/tarballs/@vercel/build-utils.tgz'
The fix is to no longer rely on the exact tarball name because we can't guarantee the name from `yarn pack` and instead rely on a pattern for the tarball name.
This removes the reliance on raw github hosting and instead relies on the Vercel deployment hosting the logo images.
Since we already have static files in each deployment (tarballs), it makes sense to start adding static images too.
### Related Issues
Adding in Nx and Rush as monorepo managers.
This will allow to help with starting zero config for both the above managers.
I have added in unit tests for both Nx and Rush.
### 📋 Checklist
#### 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
When using a `rewrite` in middleware to a relative path that does not exist, the logic gets confused and falls back to the original path.
This was caused by two changes that, in combination, caused this behavior.
1. `prevUrl` was created to keep track of route results that point to other routes, but falls back to `req.url` (`prevUrl`'s initial value): [#4033](40e4b69267 (diff-142c93a61d03a1718eb765cd25e5f18d07a95358bb27ce5d5d4da314ee2fa286R1283-R1284))
2. `prevUrl` was reassigned when handling middleware: [#7973](ee1211416f (diff-00ef6e7b63ed4cae298afc2a8c84f49247855a2506270f748e4d3e41da97ad99R1538))
Because `prevUrl` was reset back to `req.url` after the first `phase` (null) was run, the updated `prevUrl` value from middleware was lost. This only matters if the second `phase` ("filesystem") was going to be hit.
Further confusing matters, this was partially fixed by https://github.com/vercel/vercel/pull/8457 because it either returned a proxy pass (which doesn't have this problem) or assigned `req.url` to include the `rewritePath`, which meant that later when `prevUrl` would default to `req.url`, it still had come from `rewritePath`. So, this is fixed for the absolute URL case, but not the relative path case.
Given all that, I think the fix we need is to keep `prevUrl` at its current value when it's not being updated based on the `routeResult`.
---
So, I made that change here. I added a test that exercises this specific behavior.
Adds a `writeFile` function to `DetectorFilesystem` that will be used to update the various file cache maps.
**Why is this needed?**
When detecting npm7+ monorepos, we identified a performance improvement where the service can inspect the `package-lock.json` file for workspaces, and reuse the package information for each workspace in framework-detection.
The pseudo code in `vercel/api` will look something like this
For a given lockfile
```json
{
...,
"packages": {
"": {
"name": "npm-workspaces",
"version": "1.0.0",
"license": "ISC",
"workspaces": {
"packages": [
"apps/*"
]
}
},
"apps/admin": {
"version": "0.1.0",
"dependencies": {
"next": "12.2.5",
"react": "18.2.0",
"react-dom": "18.2.0"
},
"devDependencies": {
"eslint": "8.23.0",
"eslint-config-next": "12.2.5"
}
},
...,
}
```
```ts
// for each projectPath we detect in package-lock.json
// switch the cwd of the fs to the project directory
const projectFs = fs.chdir(projectPath);
// gets the package info from the lockfile
const projectPackageInfo = lockFile.packages[projectPath];
// insert this content into fs cache
await projectFs.writeFile('package.json', projectPackageInfo)
// call detectFramework, which should now have a cached "package.json" file
const projectFramework = await detectFramework(projectFs);
```
### Related Issues
Related to https://linear.app/vercel/issue/HIT-57/monorepo-detection-api-prevent-rate-limits
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
This change will allow the downstream Dev Command server be able to listen on either of `127.0.0.1` for IPv4 or `[::1]` for IPv6.
- Fixes#6639
- Fixes#8511
- Fixes#8121
- Closes#8512
- Closes#8384
Found a few tests that won't run on Windows. The project settings override test runs `mkdir -p` which errors. The other two build tests fail because they try to create symlinks.
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
Adding the ability to explicitly set the `hasPath` and `isFile` caches via `readdir`
**Why is this needed?**
For framework detection, this allows us to fetch the contents of a directory (the root directory) of a git repo, and make assumptions about the existence of files,
```ts
import frameworks from "@vercel/frameworks";
// we can make the set of all file paths needed for framework detection like this
const setOfPaths = new Set(
frameworks.frameworks
.flatMap((f) => [
...(f.detectors?.every ?? []),
...(f.detectors?.some ?? []),
])
.map((d) => d.path)
);
// then we can read the contents of the root directory of a git repo via the `DetectorFilesystem`
fs.readdir('./', { potentialFiles: [...setOfPaths] });
// The filesystem has been fully primed - any network calls from here will only happen if needed.
// This works because the logic of `detectFramework` calls `hasPath` and then `isFile` before
// fetching file contents. Since the filesystem knows this information, it doesn't have to make
// any additional network calls 🙌
const framework = detectFramework(fs);
```
### Related Issues
Related to [HIT-57](https://linear.app/vercel/issue/HIT-57/monorepo-detection-api-prevent-rate-limits)
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
When running tests locally that fail to make a fetch request, the retries add a lot of noise to debugging. This PR sets those retry counts to `0` locally, but keeps them at their current value for CI.
### Related Issues
Add handling for edge SSR in app dir, normalize the edge page routes
from app dir, like what we did for ones in `pages/`.
### 📋 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
- [ ] This PR has a concise title and thorough description useful to a
reviewer
- [ ] Issue from task tracker has a link to this PR
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### Related Issues
This ensures we properly normalize the `/` case from the `app-path-routes-manifest` as the outputs expect this to be normalized to `index`.
### 📋 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
We have code that tries to detect and highlight errors in the build logs, however it doesn't look for `Error!`, only `Error:`.
We could update that highlight code or we could update Vercel CLI to make it consistent.
This PR is the latter.
In Next.js 12, we introduce `outputFileTracing` as the default behavior. This moved `@vercel/nft` from `@vercel/next` into `next` itself so users can upgrade or downgrade Next.js if there is a bug in `@vercel/nft`.
Unfortunately, some users are setting `outputFileTracing: false` which deopts tracing back from `next` to `@vercel/next`. So we should pin `@vercel/nft` here and never upgrade in case of any bugs.
Adds a `writeFile` function to `DetectorFilesystem` that will be used to update the various file cache maps.
When detecting npm7+ monorepos, we identified a performance improvement where the service can inspect the `package-lock.json` file for workspaces, and reuse the package information for each workspace in framework-detection.
The pseudo code in `vercel/api` will look something like this
For a given lockfile
```json
{
...,
"packages": {
"": {
"name": "npm-workspaces",
"version": "1.0.0",
"license": "ISC",
"workspaces": {
"packages": [
"apps/*"
]
}
},
"apps/admin": {
"version": "0.1.0",
"dependencies": {
"next": "12.2.5",
"react": "18.2.0",
"react-dom": "18.2.0"
},
"devDependencies": {
"eslint": "8.23.0",
"eslint-config-next": "12.2.5"
}
},
...,
}
```
```ts
// for each projectPath we detect in package-lock.json
// switch the cwd of the fs to the project directory
const projectFs = fs.chdir(projectPath);
// gets the package info from the lockfile
const projectPackageInfo = lockFile.packages[projectPath];
// insert this content into fs cache
projectFs.writeFile('package.json', projectPackageInfo)
// call detectFramework, which should now have a cached "package.json" file
const projectFramework = await detectFramework(projectFs);
```
### Related Issues
Related to [HIT-57](https://linear.app/vercel/issue/HIT-57/monorepo-detection-api-prevent-rate-limits)
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
When running `vc dev` for a project using `experimental-edge` runtime and a fetch-related error occurs, the message is a little vague:
```
Unhandled rejection: fetch failed
```
In this case, the fetch promise (defined in @edge-runtime/primitives) is being rejected with a `TypeError: fetch failed` that has a `cause` property containing the actual `response.error` message. The `response.error` is the actual error and is never reported to the user.
This PR simply appends the `cause` message, if exists, to the fetch failure message.
```
Unhandled rejection: fetch failed: Error: getaddrinfo ENOTFOUND undefined
```
### 📋 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
This fixes a few warnings when running Jest that look something like:
```
jest-haste-map: Haste module naming collision: nextjs
The following files share their name; please adjust your hasteImpl:
* <rootDir>/test/dev/fixtures/10-nextjs-node/package.json
* <rootDir>/test/dev/fixtures/25-nextjs-src-dir/package.json
```
We decided to change this to an explicit label and rely on a separate action to check for correct labels (see #8464).
This action likely won't work for PRs from forks, but that might be okay because our other actions don't work for forks either.
Changes:
- added @cb1kenobi @Ethan-Arrowood to sections owned by the Vercel CLI team
- removed outdated code owners: if this was you and you believe this was in error, let us know!
- removed no-op lines
### Related Issues
As the title, support a new version of middleware-manifest of next.js that is going to be added in https://github.com/vercel/next.js/pull/39257
### 📋 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
This function name can be anything, but the current one is confusing. This is what the function gets renamed to during compilation. Let's change it back to avoid confusion.
### Related Issues
Adds configuration override support to `vc build` and `vc dev` commands.
### 📋 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
When adding the `--yes` flag to the `vc git` command's help screen, the description was copy/pasted and not accurate, so this PR improves the description to be more accurate.
### 📋 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
There were recently a few breaking changes introduced into SvelteKit. This PR clones that latest changes from a demo SvelteKit application, while retaining support for Vercel Analytics.
Deployed latest to https://sveltekit-template.vercel.app/ and confirmed analytics are sending.
This was broken since https://github.com/vercel/vercel/pull/8242, which accidentally pushed all WebAssembly modules to be nested under `global.wasmBindings` instead of being directly under the global scope.
### Related Issues
- This was broken since https://github.com/vercel/vercel/pull/8242
### 📋 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
This adds handling for the `app` outputs and adds initial tests to ensure it is working as expected.
### Related Issues
x-ref: https://github.com/vercel/next.js/pull/38420
### 📋 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
Related Issues
Previously we were only checking for a non-static version of pages/404 although this can also be the case for pages/500 so this ensures we match that handling and add a test case to prevent regression.
Fixes: slack thread
📋 Checklist
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
Related Issues
This fixes caches for data routes with middleware due to search params not matching between the non-data variant and the data variant. Additional tests have been added to ensure this is working as expected.
Fixes: vercel/next.js#39595📋 Checklist
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
As of 28.0.0, `vc link` stopped respecting `--yes` and would wait for prompt if it found a Git repository to connect. This PR passes `autoConfirm` through to the Git prompt, so that `vc link` continues to respect `--yes`.
Here's what `vc link` looks like after this PR if a user has a local Git repository:
<img width="513" alt="Screen Shot 2022-08-16 at 10 05 56 AM" src="https://user-images.githubusercontent.com/14811170/184899917-c3dc0603-370d-4c86-afb8-19758fbc051a.png">
Not sure if we want to remove the log messages to be consistent with the rest of `vc link`?
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
@leerob flagged that the language "Aborted" throughout the CLI should be changed to be more inclusive. This PR updates this throughout.
I didn't go as far as to update type names because I wanted to avoid potentially unintended consequences, but happy to also do that if we want.
### 📋 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
I ran `vc ls` for a project and I spotted a few small details that I felt compelled to make better.
### 📋 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
Currently we are adding routes for edge function un-necessarily as static edge functions don't need routes added and dynamic edge functions already have their routes included in dynamicRoutes in the routes-manifest.
Related Issues
Fixes: slack thread
📋 Checklist
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
This PR is a follow up to #8388. The tests were not running as expected because only the "vendored" test used `2.7.x` which was never failing `bundle install` to begin with. I had to add `2.7.x` to the non-vendored test to get `bundle install` to fail. The fix is to rename `2.7.x` to `2.7.0` before running `bundle install`.
#8170 shipped with a small bug: double quotes aren't stripped when pulling existing environment variables, but double quotes are stripped when reading `.env`, so if an environment variable uploaded to Vercel contained double quotes, it would always show as "Changed". This PR fixes the bug.
This error message was incorrectly telling user to use the `2.7.x` value even though it will fail `bundle install` with the following error:
```
Your Ruby patchlevel is 0, but your Gemfile specified -1
Command failed with exit code 18 (EXDEV)
```
The exact version, `2.7.0`, is necessary.
The `vc update` command is essentially a noop command that doesn't actually update the CLI. This command is not listed in the `--help` output, nor the CLI documentation. It should be safe to remove in the next major release.
### Before
Previously, the file upload progress bar would only get updated upon completion of uploading an individual file. This would cause the the progress bar to appear "chunky" when uploading large files. This problem is exasperated with #8356, since there is only a single (potentially large) file that gets uploaded, which would cause the progress bar to not render at all, making the deployment process seem "stuck".
https://user-images.githubusercontent.com/71256/184241009-ba6d1e63-a0fe-462f-804b-e58f56ec310c.mov
### After
Now, the progress bar gets updated incrementally as individual files get uploaded which makes the progress bar updates smoother and play nicely with large files. This is done by "chunking" the individual file into slices and creating a Readable stream from those chunks.
https://user-images.githubusercontent.com/71256/184241050-51832996-d42b-46fd-9a71-d8a1f87a026c.mov
#8100 added a new `vc git` command, which allows users to connect a Git provider repository, enabling them to set up a full Git workflow for their Vercel projects without having to leave the CLI.
This PR takes this functionality a step further by including it as part of the `vc link` flow. This way, users can set up a Vercel project and add a Git provider repository all in one step.
This PR is blocked by a PR to `front` which adds an option to the Git Settings page for a Project to re-enable the prompt if the user opted out (in review).
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
Related to #8102 & #8151. This PR updates the look of `vc project ls`:
- Header names are cyan
- A new "Latest Production URL" section
### Before
<img width="583" alt="Screen Shot 2022-08-11 at 10 46 03 AM" src="https://user-images.githubusercontent.com/14811170/184199554-5b298f2c-7d62-4200-a580-ddb16765c20e.png">
### After
<img width="816" alt="Screen Shot 2022-08-11 at 10 45 54 AM" src="https://user-images.githubusercontent.com/14811170/184199502-34295b2f-be7f-4289-b426-372c58f37eb6.png">
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
* Add functional but bad code
* Add docs
* Re-add thing just in case
* Fix some things
* Add a few tests
* Add test for multiple
* Add another test
* Small type fix
* Update packages/cli/src/commands/git/index.ts
Co-authored-by: Steven <steven@ceriously.com>
* Update packages/cli/src/commands/git/index.ts
Co-authored-by: Steven <steven@ceriously.com>
* Update packages/cli/src/commands/git/index.ts
Co-authored-by: Steven <steven@ceriously.com>
* Update packages/cli/test/unit/commands/git.test.ts
Co-authored-by: Steven <steven@ceriously.com>
* Update packages/cli/src/commands/git/index.ts
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
* Fix typo
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
* Update packages/cli/src/commands/git/connect.ts
Co-authored-by: Steven <steven@ceriously.com>
* Update packages/cli/src/commands/git/connect.ts
Co-authored-by: Steven <steven@ceriously.com>
* Update packages/cli/src/commands/git/connect.ts
Co-authored-by: Steven <steven@ceriously.com>
* Update packages/cli/src/commands/git/connect.ts
Co-authored-by: Steven <steven@ceriously.com>
* Update packages/cli/src/commands/git/connect.ts
Co-authored-by: Steven <steven@ceriously.com>
* return 0
* only return boolean in `promptConnectArg()`
* Remove err.meta check
* `parseRepoUrl()`: parse url without a scheme
* Remove todo
* Fix typo
* Small wording change
* Print each line instead of building buffer
* Make consistent quotes vs template literals
* Remove `multiple` variable
* Remove else
* Accept objects & rename some variables
* Move `connect-git-provider` to `git` folder
* Don't pass in `output`
* Fix small thing
* Add another test
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
Co-authored-by: Chris Barber <chris.barber@vercel.com>
This is just a small TypeScript cleanup to remove an `as Stats` cast for the "statsCache".
Also drops the `FsFiles` interface in favor of just using the built-in `Record` utility type.
Reverts vercel/vercel#8217
The previous PR had unresolved comments, but the kodiak bot automerged it. Let's revert for now, then we can continue to iterate on code in a new PR.
Right now, deployments via Vercel CLI are created by uploading every source file individually. This PR creates a tarball of the user's source files and sends the packed tarball instead. This speeds up deployment times, especially for large projects, and also bypasses the 15,000 file upload limit.
Currently, it requires a `--archive=tgz` flag. Perhaps we can enable this by default for prebuilt, but that may be for a separate PR.
### 📋 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
### 📋 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
This consolidates the logic to get the framework-specific prefixed System Environment Variables into a single shared function so each builder can reuse the same function.
- Related to #7009
- Related to #8306
In the future, this feature could be added to any other missing builders as well as `vc dev` but we'll save that for a new PR.
Previously `vc dev` would only set this env var for "create-react-app" Framework preset, but other frameworks do the "auto-open browser window" behavior as well, and respect this env var (Docusaurus, specifically).
So always set the `BROWSER=none` env var regardless of which framework preset is selected. Also simplifies the code since this was the only place `frameworkSlug` property was being used.
### 📋 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
Fixes a regression from the the refactor in https://github.com/vercel/vercel/pull/8039 that was causing the following error:
```
Error! client.prompt is not a function
```
This PR consolidates all the `test` scripts to be the same and removes the `prepublishOnly` script since we always run `build` before publishing to npm.
Instead of copying symlinked files during a build, recreate the symlink.
### 📋 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
Follow-up to #8305.
The `expect().toOutput()` call was frequently timing out before the
command writes the error to the terminal, causing the test to fail.
So wait for the command to return the exit code before running assertion
on the printed output.
Review Notes: Turn off diff whitespace.
### Refactor
This PR refactors away the use of the result of `download` for a couple of reasons:
- Keeping `files` and `downloadedFiles` in sync with the file system (like when we rename a file that starts with a bracket) is easy to forget to do, causing bugs
- Nate says that `files` is something we've wanted to move away from using anyway
- It simplifies the code in a few places
- It was getting in the way of other fixes that need to be made
We do still call `download`, but it should be a no-op most of the time.
As a consequence of these changes, this PR also addresses:
- the builder no longer leaves build artifacts around, in many cases
- the builder can compile files that start with brackets again; routes don't seem to allow this to file to respond to a dynamic segments yet, though
### Next Steps
Upcoming PRs will resolve builder issues:
- bracket endpoints responding to dynamic segments
- exported function name conflict handling
- compilation targets should only apply to the source code build, not the analyze go utility
### Operating In-place
We also now have a cleanup step that clears out created files, created directories, and undoes file renames. This fixes an issue where multiple builds on the same directory would fail. It also cleans the user's project code when they are using `vc build`.
Ideally, we'd probably copy all of the code to a separate location, then freely do filesystem operations there. It's not clear to me if this is preferred for large projects because it would have to happen once per endpoint: 100 Go files would cause 10,000 (100 * 100) file copies (or symlinks).
It has to copy once per endpoint because we potentially need all of the files around in case any of them are imported. If we had nft-style tracing for Go, we could copy only what we needed.
This gets more complex in the next step where the exported function names will be renamed during compilation to fix the name conflict issue.
Previously, our test fixtures used to use a probes prop in `vercel.json` that was removed right before it was deployed.
This PR allows a separate `probes.json` file with the same content to separate the test fixture input from the test probes.
This allows us to test real "zero config" deployments without a `vercel.json` file.
Removes the legacy config file migration logic from back in the days when Zeit CLI supported multiple "providers". This was from a _very_ long time ago and we should expect that anyone who would have migrated at this point, has.
Right now, `vc inspect` fails to find a deployment if you include `http://` before it. But it works with no scheme and with `https://`.
Since it appears no scheme is what the API looks for anyway, and to avoid confusion, this PR strips any included scheme from the `deploymentIdOrHost` argument.
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
Ensures that errors that are serialized into `builds.json` are also printed to the terminal when running the `vc build` command.
Co-authored-by: Steven <steven@ceriously.com>
#8170 added a new message at the end of `vc env pull` which shows a delta of what was added, modified, and removed. Some people shared feedback that the yellow chalk color and `~` prefix to indicate modified variables was confusing. This PR instead keeps the prefix as `+` with a green color, but adds a `(Modified)` suffix at the end of every modified variable.
<img width="638" alt="Screen Shot 2022-08-03 at 10 18 28 AM" src="https://user-images.githubusercontent.com/14811170/182670327-5a3df6db-d84d-40a1-956b-9cf159501759.png">
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
* Fix _next/data resolving priority for dynamic routes
* Apply suggestions from code review
* Ensure we match middleware for _next/data without header
* fix nested middleware case
* Update data routes generating
* Add version lock for non-nested middleware
* use path.posix
Middleware server setup wasn't logging errors the same way that dev server setup was. This meant that middleware instantiation errors (like invalid config) would cause requests to 500, but no errors to be logged to the console.
This PR updates the invalid config error, makes sure errors in this area are logged out, and adds a test for this behavior.
**It may be appropriate to fail the deploy (and crash `vc dev`) in this case instead, though. What do others think?**
---
During `vc dev` with middleware that has an invalid `config.matcher` value...
Before: You see a 500 response in the browser and no output in the terminal.
After: You see a 500 response in the browser and this output in the terminal:
```
Error! Middleware's `config.matcher` values must start with "/". Received: not-a-valid-matcher
```
---
Related Issue: https://github.com/vercel/edge-functions/issues/220
Some builders, such as `@vercel/next`, return both the symlinked directory and the resolved file.
When `vc build` iterates over the files to recreate them in `.vercel/output`, it fails with `EEXIST: file already exists` when creating the symlink because it first creates the file `node_modules/<symlink>/package.json` and then attempts to create the symlink `node_modules/<symlink>`.
This happened to work before `vc build` because yazl would accept the symlinked directory instead of the package.json file, so this PR is created to match that behavior.
Remove `meta.isDev` checks inside the `build` function because it's never set there. Instead, `startDevServer` would be used.
Also restored the Go tests in a partial form. Will fix the Go builder issues and make sure those features are tested completely in follow-up PRs.
* update edge-runtime to allow `instanceof` to work with primitives
* finishin upgrading edge-runtime
* update to latest
* fix merge
* remove dev only from test
The dev integration tests compare `vc dev` with a real deployment to make sure the results are the same. This PR ensures the deployment uses the same version of Vercel CLI as the local `vc dev` instance.
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
Since CI is already setup to run Build and then Test, we don't need to add it as an explicit turbo dependency so this PR removes `dependsOn: ['build']` from each test task.
In fact, the `test-unit` step doesn't need `build` in most cases now that jest is configured to run the TS sources directly.
This PR will also improve the time it takes to run the "Find Changes" job since it can ask jest for relevant files that changed without waiting for a build. This drops the time down from 2 minutes to 8 seconds.
For Edge Functions, we are now considering the `"browser"` and `"module"` fields of packages to find the proper entrypoint. This PR updates `@vercel/node` to consider those same fields when using the node-file-trace tracing, so that the proper files get included in the output Edge Function.
The `alias` command has been added to the `vercel --help` screen.
### Related Issues
> https://linear.app/vercel/issue/VCCLI-221/alias-command-missing-on-vc-h-help-screen
### 📋 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
This PR update the tests suite to wait for Vercel CLI tarball and then use that tarball to run E2E tests.
This is valuable because it will package all the packages in this monorepo to make the tests follow more closely what will happen in production once merged.
Since the current "Find Changes" step takes about 2 minutes, we run that first (it happens concurrently with the tarball preparation). Then once we complete "Find Changes" we wait for the tarball but it will likely be ready by that point since it also takes about 2 minutes. After both of those steps, the E2E tests continue as usual but with the `VERCEL_CLI_VERSION` set to the tarball.
- Related to #7967
- Closes#8245
- Closes#8227
The edge runtime context we were providing was necessary to have `ncc`-bundled code run, but after switching to `esbuild`, we didn't update this list.
This PR trims the values down to only what's necessary for `esbuild`-bundled code to run. It also adds comments about why these values are necessary.
This updates the API that generates tarballs so that it doesn't need to generate tarballs for every Serverless Function and instead generates it one time. This cuts the time in half.
* [node] Add WebAssembly importing support for the @vercel/node builder
* add comment about the original source
* trim down values to only what is required for esbuild wrapping logic
* Revert "trim down values to only what is required for esbuild wrapping logic"
This reverts commit c04dacad99f25156938dccdf2f29aac6e8282564.
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
### Related Issues
Adds `.vercel` path to the ignore list regardless if `zeroConfig` is enabled. This fixes a bug where the `.vercel` folder was being copied into the resulting `.vercel/output/static` directory after running `vc build` with `distDir: "."` configured for static-build.
### 📋 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
Featuring:
- Aliases are now shown
- `readyState` –> `status` in "General" section
- `createdAt` –> `created` in "General" section
- Update `stateString` to support more states & be more visually appealing
### Before
<img width="754" alt="Screen Shot 2022-07-14 at 3 10 40 PM" src="https://user-images.githubusercontent.com/14811170/179097164-df7acd8a-d677-4e75-b7d5-b8ec6cf9bb12.png">
### After
<img width="748" alt="Screen Shot 2022-07-14 at 3 10 29 PM" src="https://user-images.githubusercontent.com/14811170/179097170-137d8977-60d6-402d-825e-8b0fb3025969.png">
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
The version of `@vercel/ncc` that was being used in this repo is rather old. Let's update to the latest version. Specifically, this is a baby step towards allowing CLI to become ESM format.
This applies the same chunking algorithm from `@vercel/static-build` tests to `@vercel/node` tests that we can run up to 5 integration tests concurrently.
### Related Issues
Adds a `isZeroConfig` check to static-build so that when `"zeroConfig": true` is enabled the correct settings are resolved.
### 📋 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
This PR fixes a couple issues where `vercel build` was not correctly detecting the package.json files
```
Error: @vercel/node:test: ERROR: frontend/index.ts(1,12): error TS2580: Cannot find name 'require'. Do you need to install type definitions for node? Try `npm i --save-dev @types/node`.
```
It also fixes an issue where all deployments were incorrectly detecting the lock file because the lock file doesn't always live in the same directory as the package.json file. So we need to do 2 passes: one to find the nearest package.json and one to find the nearest lock file.
Only consider the `.vercel/.env.${target}.local` file when loading env vars at the beginning of `vercel build`.
If a project-level `.env` (or `.env.production` or whatever) file needs to be loaded then it is the responsibility of the frontend framework's build command to consider those files (i.e. CRA build, `next build`, etc.)
I don't think anyone is using this command anymore in the world of M1.
Anyways, we should be using `ts-node` to execute the CLI from source code instead of skipping steps at build-time to iterate quickly.
This PR adds a new message to the end of `vc env pull` which shows delta of what was added, changed, and removed.
Example: you have a local `.env` file in a directory linked to a Vercel project. You change `TEST_1`, remove `TEST_2` via `vc env rm TEST_2`, and add `TEST_3` via `vc env add`. Then you run `vc env pull`. Here's what you will see:
```
> Updating existing .env file
> Downloading `development` Environment Variables for Project name
✅ Updated .env file
+ TEST_3
~ TEST_1
- TEST_2
```
<img width="562" alt="Screen Shot 2022-07-20 at 11 09 56 AM" src="https://user-images.githubusercontent.com/14811170/180064534-2ff5facb-95cb-4712-aaad-cbb47490cebe.png">
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
`ts-eager` isn't really maintained anymore and doesn't support ESM packages.
`ts-node` with SWC is more or less just as fast, so let's use that instead since it's well maintained any we can dogfood SWC more.
Pull the Vercel Analytics ID in the `vercel pull` command, so that `vercel build` can set the `VERCEL_ANALYTICS_ID` environment variable at build-time for the frontend framework to utilize.
This test sometimes times out on Windows. When it succeeds, it takes ~6 seconds. When it fails, we don't know how long it would have taken, but the current timeout is 7 seconds. Let's try 10 seconds and see if that's better.
If you run `yarn changelog` when your IP is already rate limited by github, you'll get an error. This allows you to set a [Github PAT](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) to get past the generic rate limit.
Given a PAT with value `MY_PAT_TOKEN`, you can run:
```
$ GITHUB_TOKEN=MY_PAT_TOKEN yarn changelog
```
If you do get an error, it now actually shows up in the output:
```
$ yarn changelog
yarn run v1.22.18
$ node utils/changelog.js
Error: Failed to fetch releases from github: API rate limit exceeded for 98.139.180.149. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)
```
Jest was saying that there's an open handle in the unit tests due to the `crypto.pbkdf2Sync()` call in this metrics file, so lazy-load that object in the case when metrics should not be collected.
### Related Issues
Updates to the latest version of `@vercel/nft` which adds fs concurrency limits to help alleviate memory usage.
x-ref: https://github.com/vercel/nft/pull/301
### 📋 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
The logic that determines if a builder needs to be installed has a check to see if the builder should already be bundled: `isBundledBuilder`. This was looking for specific conditions that made it (1) a bit hard to follow and (2) very sensitive to `canary` tags (and having "canary" in the version specifier).
This causes general development problems because local changes weren't always used by local CLI builds. Depedendant packages (like `@vercel/node`) would be installed from the latest `canary` release instead.
This caused problems in CI and released CLI versions where the latest `canary` of dependant packages might be rather old, causing that old code to be used instead of the latest non-canary releases.
The issue was mitigated for now by publishing canary releases for all packages.
---
Paired with @styfle @MatthewStanciu.
@TooTallNate: Is this change too broad? Are there cases where we wouldn't want to do this?
### Related Issues
This updates to filter the `routes-manifest` and `pages-manifest` to only include entries for the pages that are being included in the specific serverless function. This fixes the case where multiple dynamic routes could match a path but one is configured with `fallback: false` so shouldn't match when executing for a different dynamic route.
A regression test for this specific scenario has been added in the `00-mixed-dynamic-routes` fixture.
### 📋 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
When an edge function has no response during `vc dev`, we were seeing an unhelpful error message:
> The event listener did not respond.
Now, we'll see a much more specific error message:
> Unhandled rejection: Edge Function "api/edge-no-response.ts" did not return a response.
> Error! Failed to complete request to /api/edge-no-response: Error: socket hang up
### Related Issues
1. exception from python 3.10:
```
TypeError: As of 3.10, the *loop* parameter was removed from Queue() since it is no longer necessary`
```
Remove the deprecated argument `loop` from `Queue`, which can also be omitted in python version < 3.10
2. exception from Sanic > 21.3:
```
File "C:\Users\Kevin\AppData\Local\Temp\zeit-fun-03f18b2d2c7d7\sanic\signals.py", line 93, in get
group, param_basket = self.find_route(
TypeError: 'NoneType' object is not callable
```
As of Sanic > 21.3, it cannot serve requests immediately after initializing, instead, we need implement the [ASGI lifespan protocol](https://asgi.readthedocs.io/en/latest/specs/lifespan.html) and wait for the startup event completed.
here I complemented the protocol copied from (same source of the previous HTTP procotol): <https://github.com/jordaneremieff/mangum/blob/main/mangum/protocols/lifespan.py>
### Related link:
https://github.com/encode/uvicorn/pull/498
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
Co-authored-by: Steven <steven@ceriously.com>
Two features that handle a user's local Git config have been shipped:
- #8100
- #7910
Both of these features currently pull only from the user's remote origin URL. This covers 90% of cases, but there are cases in which the user has more than one remote URL, and may want to use one other than the origin URL, especially in `vc git connect`. This PR:
- Adds support for multiple remote URLs in a user's Git config
- Updates `vc git connect` to prompt the user to select a URL if they have multiple remote URLs
- Updates `createGitMeta` to send the connected Git repository url by default, origin url otherwise
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
Update `node-fetch 2.6.1 -> 2.6.7` to fix high severity security vulnerability: Exposure of Sensitive Information to an Unauthorized Actor (https://github.com/advisories/GHSA-r683-j2x4-v87g).
`node-fetch` was updated in the root, `api`, `build-utils`, `cli`, `client`, `node`, and `static-build`.
### Related Issues
> https://linear.app/vercel/issue/VCCLI-196/update-vercelnode-dep-node-fetch-261-267
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
Right now, `vc env pull` only pulls development environment variables. This PR adds a new flag, `--environment,` which allows users to specify which environment to pull from.
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
If an error happens outside of a Builder (i.e. `detectBuilders()` function fails), then write the serialized error into the `builds.json` file at the top-level of the file (there is no `builds[]` when an error happens at the top-level).
This matches the behavior in production and prevents the error:
```
> Error! Your `package.json` file is missing a `build` property inside the `scripts` property.
```
If we don’t know the error, we should not assume it has a stack prop and instead print the whole thing to avoid accidentally printing `undefined`.
- related to https://github.com/vercel/vercel/discussions/8043
This is a semver major change to the public API for `@vercel/routing-utils` which includes the following breaking changes.
1. `getTransformedRoutes({ nowConfig })` props changed to `getTransformedRoutes(nowConfig)`
2. `type Source` renamed `type RouteWithSrc`
3. `type Handler` renamed `type RouteWithHandle`
4. `interface VercelConfig` removed
5. `type NowConfig` removed
6. `type NowRewrite` removed
7. `type NowRedirect` removed
8. `type NowHeader` removed
9. `type NowHeaderKeyValue` removed
This updates our `allowQuery` generating to ignore all query values for build-time prerender paths as these will match before dynamic routes since they are filesystem routes and the query values will not be overridden properly like they are for fallback prerender paths. This also adds testing for both prerender path types with on-demand ISR to ensure the cache is updated as expected regardless of the query.
Deployment with patch can be seen here https://nextjs-issue-odr-simple-hrjt2dagm-ijjk-testing.vercel.app/
### Related Issues
x-ref: https://github.com/vercel/next.js/issues/38306
x-ref: https://github.com/vercel/next.js/issues/38653
### Related Issues
Noticed this log was not being converted to a string so we're losing some context so this corrects in case we have a failure on this step in the future.
Fixes: https://github.com/vercel/vercel/runs/7344626478?check_suite_focus=true#step:8:258
### 📋 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
### Related Issues
Updates to latest turbo which includes patches for cached files.
x-ref: [slack thread](https://vercel.slack.com/archives/C02CDC2ALJH/p1657767763630359?thread_ts=1657757803.039099&cid=C02CDC2ALJH)
### 📋 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
When a Builder returns an output asset that contains irregular slashes (multiple slashes or leading/trailing slashes), then have them be removed from the file path before creating the output asset.
This fixes an edge case where `@vercel/next` could end up outputting a Serverless Function with a trailing slash (i.e. `en-US/`). Before this PR, that would be serialized to the filesystem at `en-US/.func`, but after this fix it's saved in the correct `en-US.func` directory.
When a build fails, store the serialized Error in the "builds.json" file under the "build" object of the Builder that failed.
Example:
```json
{
"//": "This file was generated by the `vercel build` command. It is not part of the Build Output API.",
"target": "preview",
"argv": [
"/usr/local/bin/node",
"/Users/nrajlich/Code/vercel/vercel/packages/cli/src/index.ts",
"build",
"--cwd",
"/Users/nrajlich/Downloads/vc-build-next-repro/"
],
"builds": [
{
"require": "@vercel/next",
"requirePath": "/Users/nrajlich/Code/vercel/vercel/packages/next/dist/index",
"apiVersion": 2,
"src": "package.json",
"use": "@vercel/next",
"config": {
"zeroConfig": true,
"framework": "nextjs"
},
"error": {
"name": "Error",
"message": "Command \"pnpm run build\" exited with 1",
"stack": "Error: Command \"pnpm run build\" exited with 1\n at ChildProcess.<anonymous> (/Users/nrajlich/Code/vercel/vercel/packages/build-utils/dist/index.js:20591:20)\n at ChildProcess.emit (node:events:527:28)\n at ChildProcess.emit (node:domain:475:12)\n at maybeClose (node:internal/child_process:1092:16)\n at Process.ChildProcess._handle.onexit (node:internal/child_process:302:5)",
"hideStackTrace": true,
"code": "BUILD_UTILS_SPAWN_1"
}
}
]
}
```
#8085 removed the clipboard copy feature in `vc deploy`, along with the `--no-clipboard` flag. Right now, the CLI exits and returns an error when someone includes the `--no-clipboard` flag. This PR instead consumes the flag and warns the user that the flag is deprecated.
### 📋 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
A function `formatProvider` wasn't imported in the `Project` mock endpoint. This wasn't caught before #8100 was merged, and dodged CI.
### 📋 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
`config.projectSettings` is not available when running `@vercel/remix` directly (i.e. when not using `vc build`), so calculate the correct root directory value based on the `workPath` relative to the `repoRootPath` value.
This PR adds a new subcommand `vc git`, which allows you to create a Git provider repository from your local `.git` config to your Vercel project.
Usage:
- `vc git connect` – connects a Git provider repository
- `vc git disconnect` – disconnects a Git provider repository
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
"solidstart" framework doesn't need to use the FS API v2 Builder anymore since:
1) Newer versions output Build Output API v3
2) Older versions that output FS API v2 will be handled by the compatbility shim that was added in https://github.com/vercel/vercel/pull/7690
This will enable Next.js to compile and set `vercel` as the edge runtime provider (`EdgeRuntime` global),
which can allow different libraries/customers to have different code running depends on the runtime environment (`edge-runtime` vs `vercel`).
### Related Issues
- https://github.com/vercel/next.js/pull/38331
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### Tests
The Next.js feature was not merged yet, so it still can't be tested.
- [ ] 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
There's a [Next.js PR](https://github.com/vercel/next.js/pull/38492) to include binary assets in Edge Functions. This PR enables to declare assets in the `EdgeFunction` constructor.
This is a configuration level setting, compared to WebAssembly modules which the `middleware-manifest.json` converts into `import` statements. This is because the asset generation is done in Webpack and it is not dynamic, it's a static string. We can use AST to replace it but we're risking in:
* worse performance
* accidentally replacing a string that isn't an asset
A test I wrote for a previous PR (https://github.com/vercel/vercel/pull/8112) was failing once in ~every 5 runs. This PR makes the test reliable.
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
The Vercel API's `detect-framework` API contacts GitHub's API using its own file adapter.
However, currently the `detectFramework` function in the Vercel CLI (on which the API depends) calls the file system adapter in series using a `for` loop. This results in large amounts of lag when in a networked situation such as calling GitHub's API as each API call takes a couple hundred milliseconds.
I propose changing `detectFramework` to process the directories it scans in parallel.
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
This debug log was originally added in #7871 because corepack has no output by default. In particular, it was nice to see the first deployment was not stalled when the package manager is being installed.
That being said, this gets noisy really fast because cache detections also print a log line.
For example, here's a deployment that prints 3 times:
```
Detected ENABLE_EXPERIMENTAL_COREPACK=1 and "npm@8.10.0" in package.json
Running "install" command: `npm install --prefix=.. --no-audit --engine-strict=false`...
2022-07-11T18:27:00.696Z corepack Reusing npm@8.10.0
356 packages are looking for funding
Running "npm run vercel-build"
2022-07-11T18:27:06.664Z corepack Reusing npm@8.10.0
> front@0.0.0 vercel-build
> npm run buildonly && npm run build:rss
2022-07-11T18:27:07.088Z corepack Reusing npm@8.10.0
> front@0.0.0 buildonly
> next build
```
I think its best to let users add this env var themselves if they want to debug what corepack is doing, so this PR removes that environment variable.
This is a follow-up to #8094 which debug logs errors.
### 📋 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
This is a follow-up to #8091 which:
- Makes `vc project` the default command, with `vc projects` aliased to `vc project` (previously it was not clear in the code which one was the "real" command)
- Makes some helper names for `ls` more specific
### 📋 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
Since the `vc project` command is about to be expanded with 2 new subcommands, I think it makes sense to do a little bit of refactoring. The current `vc project` command is all in one file, with the logic for subcommands nested within if statements. I think the structure of `vc project` should look more like `vc env`, which is consistent with how commands with subcommands look throughout the rest of the codebase.
This PR moves the logic for the `project` subcommands into their own files.
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
### Related Issues
- Fixes https://github.com/vercel/customer-issues/issues/597
`vc deploy` currently fails with a confusing error if the user has a corrupt `.git` directory. This is caused by `create-git-meta` improperly handling the scenario where it detects a `.git` directory but cannot find git information. This PR handles this error.
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
The `middlewarePath` property was not correctly stripping
the root directory setting from the value, causing Middleware
to not work correctly with Root Directory.
`vercel-sapper` is a case of a 3rd party Builder that does not export a `version` property. In this case, we should treat it the same as a `version: 2` Builder since its return value is compatible.
Adds a new `@vercel/hydrogen` Builder package so that Vercel can support Shopify Hydrogen projects with zero config. It outputs an Edge Function for the server-side render code and includes a catch-all route to invoke that function after a `handle: "filesystem"` to serve static files that were generated by the build command.
**Examples:**
* [`hello-world-ts` template](https://hydrogen-hello-world-otm2vmw6w-tootallnate.vercel.app/)
* [`demo-store-ts` template](https://hydrogen-demo-store-1gko2fst3-tootallnate.vercel.app/)
This PR adds a new subcommand, `vc project connect`, which connects a Git provider repository to the current project. Previously, this could only be done via the Dashboard.
This is the first part of a larger project—the goal is to include this functionality within `vc link`, so that you never have to leave the CLI if you want to set up a new Vercel project that's connected to Git.
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
- https://github.com/vercel/vercel/pull/8053
While writing tests for this PR, I added a mock project endpoint that always returned a default project. This was probably incorrect and no longer needed (tests pass without it). I should have removed it before merging #8053, but I didn't catch this before merging.
### 📋 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
Currently, `vc ls` is scoped to your team, and you have to type out a project name if you want to see deployments for a project. This PR instead scopes it to the linked project.
Under these changes, `vc ls` still works similarly to how it currently works: users can still specify a project name to get the deployments for a project. The difference is that:
1. The selected team is the one that the linked project belongs to, instead of the one that the user has selected.
2. `vc ls` with no arguments displays the latest deployments for the linked project.
This is the first part of a larger effort to change the behavior of `vc ls`, plucked from https://github.com/vercel/vercel/pull/7993. More PRs to follow.
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
https://vercel.slack.com/archives/C03F2CMNGKG/p1656971502881949
Right now, `vc deploy` automatically copies the deploy url to your clipboard after the deployment has finished. You can opt out via the `--no-clipboard` flag, but the feature is enabled by default.
This is strange behavior—there's no indication that the CLI will hijack your clipboard, and you don't know it's been hijacked until after it happens.
This PR removes the clipboard copying feature as well as the `--no-clipboard` flag.
### 📋 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
This ensures we update the canary dist-tag when publishing stable releases as we no longer need to do separate canary publishes.
### Related Issues
x-ref: [slack thread](https://vercel.slack.com/archives/C65QW9PN1/p1657049930618119?thread_ts=1656362480.574099&cid=C65QW9PN1)
### 📋 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
This PR fixes a bug where corepack (#7871) was not correctly setup because the lockfile autodetection and node version autodetection was overriding the PATH.
It also fixes a bug where the log output was printed twice because we incorrectly prepended the PATH twice.
The Saber example had a lock file but the test did not.
This PR copies the lock file since the latest version of Saber doesn't work with the latest Vue.
```
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './package' is not defined by "exports" in /vercel/path0/node_modules/vue/package.json
at new NodeError (node:internal/errors:372:5)
at throwExportsNotFound (node:internal/modules/esm/resolve:472:9)
at packageExportsResolve (node:internal/modules/esm/resolve:753:3)
at resolveExports (node:internal/modules/cjs/loader:482:36)
at Function.Module._findPath (node:internal/modules/cjs/loader:522:31)
at Function.Module._resolveFilename (node:internal/modules/cjs/loader:919:27)
at Function.resolve (node:internal/modules/cjs/helpers:108:19)
at module.exports (/vercel/path0/node_modules/saber/dist/webpack/webpack.config.js:30:58)
at Saber.getWebpackConfig (/vercel/path0/node_modules/saber/dist/index.js:195:58)
at VueRenderer.build (/vercel/path0/node_modules/saber/dist/vue-renderer/index.js:232:39)
```
The `@vercel/build-utils` package was meant be shared functions necessary for writing a Vercel Builder (aka Runtime).
This package has since bloated into the catch-all package for anything that wasn't a Builder.
This PR removes the bloat in favor of a new package, `@vercel/fs-detectors`. It also removes the need for `@vercel/build-utils` to have a dependency on `@vercel/frameworks`.
- Related to #7951
This PR is a follow-up to #8039, which provides an intuitive syntax for writing unit tests for interactive CLI commands.
The heart of this is the new `await expect(stream).toOutput(test)` custom Jest matcher, which is intended for use with the mock Client `stdout` and `stderr` stream properties. The `test` is a string that will wait for the stream to output via "data" events until a match is found, or it will timeout (after 3 seconds by default). The timeout error has nice Jest-style formatting so that you can easily identify what was output:
<img width="553" alt="Screen Shot 2022-06-29 at 10 33 06 PM" src="https://user-images.githubusercontent.com/71256/176600324-cb1ebecb-e891-42d9-bdc9-4864d3594a8c.png">
Below is an example of a unit test that was added for an interactive `vc login` session:
```typescript
it('should allow login via email', async () => {
const user = useUser();
const exitCodePromise = login(client);
// Wait for login interactive prompt
await expect(client.stderr).toOutput(`> Log in to Vercel`);
// Move down to "Email" option
client.stdin.write('\x1B[B'); // Down arrow
client.stdin.write('\x1B[B'); // Down arrow
client.stdin.write('\x1B[B'); // Down arrow
client.stdin.write('\r'); // Return key
// Wait for email input prompt
await expect(client.stderr).toOutput('> Enter your email address:');
// Write user email address into prompt
client.stdin.write(`${user.email}\n`);
// Wait for login success message
await expect(client.stderr).toOutput(
`Success! Email authentication complete for ${user.email}`
);
// Assert that the `login()` command returned 0 exit code
await expect(exitCodePromise).resolves.toEqual(0);
});
```
**Note:** as a consequence of this PR, prompts are now written to stderr instead of stdout, so this change _may_ be considered a breaking change, in which case we should tag it for major release.
In some rare cases, `npm bin` exits with code 7, but still outputs the right bin path.
To reproduce, try:
```
npm init -y
echo "//registry.npmjs.org/:_authToken=${NPM_TOKEN}" > .npmrc
vc
# enter "echo build" for the build command, leave the other configuration as default
```
The build will fail with `Error: Command exited with 7` because `npm bin` fails with code 7, for some reason.
In this PR, we do 2 things:
(1) Ignore exit codes from `npm bin`. It still outputs the right path when it exits with code 7 so we just read the output and check if it's a valid path.
(2) Throw a more specific error message when `npm bin` fails to give us the bin path. The current error was hard to debug because it looked like it was coming from the install commmand. We can do better by emitting a custom error.
Alternative considered for (2): Do not throw errors. If `npm bin` fails, emit a warning and let the build continue.
Related Issues:
- https://github.com/vercel/customer-issues/issues/585 (internal)
There's some cleanup directory walking logic that was choking when
a Lambda outputs a file with a broken symlink. We shouldn't need to
traverse into those directories in the case of a symlink anyways, so use
`lstat()` instead of `stat()` to prevent that filesystem call from
throwing an error.
If there is no `api` directory, then you run `vc dev`, then you create a new function `api/some-func.js`, then this file would not be served as a new function.
This was being caused by incomplete "new file" handling logic. This PR ensures that the proper detection is done in each new file (`getVercelConfig`) that populates key properties (`apiDir`, `apiExtensions`, and extensionless `files`) for determining when a file is used to serve a request.
When edge functions error, they were showing a basic text response instead of the error template. They were also sending a 502 status code instead of a 500.
This PR makes the error handling of Edge Functions consistent with Serverless Functions when executed through `vc dev`. If we want to update the error templates themselves, we can do that in a separate PR.
**Note:** Production currently treats Edge Function errors differently from Serverless Function errors, but that's a known issue that will be resolved.
---
*I deleted the original outputs (terminal and browser screenshots) because they are out of date and added a lot of content to this page. See my latest comment for updated examples.*
`vc bisect` currently prepends `https://` to a passed-in url if it doesn't begin with https—which means that if someone passes in a url that begins with `http://`, it'll turn the url into `https://http://url.com`. This PR fixes this.
### 📋 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
Adds initial support for a root-level `middleware.js` / `middleware.ts` file in the `vercel dev` CLI command. This leverages the existing Edge Function invoking logic in `@vercel/node`'s `startDevServer()` function and applies the necessary response / rewrites / mutations to the HTTP request based on the result of the middleware invocation.
Allows to specify a string or array of paths/globs for when a root-level
Middleware should be invoked.
```javascript
export const config = {
matcher: ['/about/:path*', '/dashboard/:path*'],
}
```
This ensures we correctly match `basePath` for the `_next/data` resolving routes. The tests in the below referenced PR already cover this change so no new fixtures have been added here as they would rely on those changes landing first.
### Related Issues
x-ref: https://github.com/vercel/next.js/pull/37854
### 📋 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
This is the last missing piece in the size validation of edge functions. Since WASM binaries are not bundled in the user JavaScript file, we also need to count their sizes in the validation.
### Related Issues
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
Include a `requirePath` property to each "build" in the `builds.json` file which is the absolute path to the Builder entrypoint that was executed.
This gives context as to which Builder was invoked by `vc build` which helps with introspection / debugging.
Some new imports were introduced recently but are missing from the `"dependencies"` object, so they were missing when the package was installed from the npm registry.
The `probes` in the vercel.json files in tests fixtures weren't allowing both `mustContain` _and_ `responseHeaders` probes due to an `else` block. This PR allows to combine those checks into the same probe test.
Gets rid of the annoying ts-jest update warning:
```
ts-jest[ts-jest-transformer] (WARN) Use 'ts-jest' entry point in v28 will resolve in refactored transformer. If you wish to use legacy transformer, please adjust your Jest 'transform' config. For example:
module.exports = {
transform: {
'^.+\\.tsx?$': 'ts-jest/legacy'
}
}
```
Add support for Edge Functions when using `vercel dev`. This uses the [`edge-runtime`](https://edge-runtime.vercel.app/) to emulate the proper environment, [`ncc`](https://github.com/vercel/ncc) to parse the entrypoint (supporting TypeScript and importing node modules), and some custom marshaling to pass the request/response values through.
In a previous PR, the entrypoint path extension was stripped in `vc dev` to match the behavior of production deployments (`/api/user.js` => `/api/user`). However, it was supposed to map back to the original file extension before invoking the matching builder. This PR fixes the mapping for dynamic paths with ESM, such as `/api/[id].mjs` => `/api/[id]`.
Currently, git metadata is not included on the Vercel dashboard when a project is deployed via the CLI. This PR populates the git metadata.
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
### Related Issues
This PR adds vercel.json configuration overrides support for both new and existing project flows through the CLI. It includes integration and unit tests.
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
Adds support for `config.middleware` property in `@vercel/node` to output an Edge Middleware (by including a catch-all route in the output).
Also updates the zero-config detection logic to schedule a build of root-level `middleware.js`/`middleware.ts` files with `@vercel/node` with this middleware option enabled.
<img width="1174" alt="Screen Shot 2022-05-19 at 3 53 55 PM" src="https://user-images.githubusercontent.com/35947020/169402845-4eb70a24-9954-44ac-8726-a6b56161d58c.png">
If there is no workspace detected, we still want to check if there are potential projects in the monorepo. An example of this case would be:
<img width="202" alt="Screen Shot 2022-05-19 at 10 29 12 AM" src="https://user-images.githubusercontent.com/35947020/169336400-e69845e3-616e-4857-80fe-c2614a65352a.png">
The directories `backend/app-three`, `frontend/app-one`, `frontend/app-two` all have definitions within their `package.json` files that define a framework assosiated with the project. This is what distinguishes them from the `package.json` files within `backend` and `frontend`
`getProjectPaths` loops through a depth of 3 (this can be changed but in most cases of this it won't be more than 3). For each directory it recursively calls itself until it finds a `package.json` file. It then checks if the directory has a framework defined and if so it adds the path to the final return value of all projects.
If any `skipPaths` are sent into the function, no projects will be looked for within those path(s). This would include the case for a hybrid monorepo where a workspace has already been detected
### Related Issues
> Fixes#1
> Related to #2
### 📋 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
`vc build` runs `vc pull` if no project settings are found locally. By default, `vc pull` pulls development environment variables, but we want either preview or production environment variables in the context of `vc build`. This PR adds a flag to the internal `vc pull` call to pull the correct environment variables.
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
Fixes an issue brought up in https://github.com/vercel/og-image/issues/207
The problem is that we allow a corner case with `vc dev` to run the build script, but this can break if the user ran `vc build` first due to the BOA V3 detection.
The workaround is to delete the BOA V3 directory when there is no Development Command provided since that will run the Build Command during development.
We also add a nicer error in the case when someone actually intended to emit BOA V3.
* Add regression test for nested middleware
* [next] Allow edge api endpoints in Next.js
This reverts commit d4cef69cc9 (#7898)
* delete `functions`, not `middleware`
* Add an assertion
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Gets the package paths from the workspace definition for a given git repository
```ts
/**
* Gets the list of workspace package paths based on the configuration
*
* @example
*
* my-repo
* |-- packages
* | |-- api-1
* | |-- api-2
* |-- package.json
* |-- pnpm-workspaces.yaml // packages: ["packages/*"]
*
* const fs = new ... // based on 'my-repo'
* const workspace = { ..., type: "pnpm" }
* getWorkspacePackagePaths({ fs, workspace }) => [
* "my-repo/packages/api-1",
* "my-repo/packages/api-2"
* ]
*/
function getWorkspacePackagePaths(fs: DetectorFilesystem, workspace: Workspace): string[]
```
### Related Issues
Closes https://github.com/vercel/vercel/issues/7749
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
Adds support for `@vercel/node` to return an `EdgeFunction` output when it detects `runtime: 'experimental-edge'` from the static `config` object. This is implemented in `@vercel/node` so that it can share the same file extension (`.js`/`.ts`) as Node.js Serverless Functions without modifying the zero-config detection logic.
**Example:**
```js
export const config = {
runtime: 'experimental-edge',
};
export default req => {
return new Response(`Hi, from an Edge Function!`);
};
```
* Ensure middleware route comes before beforeFiles rewrites
* update test
* add version lock and more tests
* update nested middleware test for version lock
Node 12 is EOL and we're starting to reference packages that don't install on node lower than 14, such as nuxt@3 and remix. Let's update to 14 for now.
---
Reimplements: https://github.com/vercel/vercel/pull/7819
This PR adds support for experimental [corepack](https://nodejs.org/api/corepack.html) to `vc build`.
Since this is still experimental, we only enable if the env var `ENABLE_EXPERIMENTAL_COREPACK=1` is set.
#### 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`
This PR updates the way we handle warning for engines.node in `package.json`.
- should not warn when the engines version satisfies the project settings (previously it was an exact match)
- should warn when engines version is exact instead of range since it cannot be satisfied exactly
- should warn when engines version is greater than since it might introduce breaking changes for a future node.js version
This PR adds support for extracting `config` from swc's AST. `static-config` supports parsing from the source program but in some cases we already have parsed an AST to do other static code analysis.
### Related Issues
None
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
[cli] Add `vc build` integration test
Adds a `vc build` integration test to ensure the ncc'd CLI works as
expected to supplement the unit tests from #7869.
Co-authored-by: Steven <steven@ceriously.com>
These tests are asynchronous and would sometimes fail if the second call started before the first call finished. This PR fixes the usage since the function returns a promise.
This fixes an issue when an external contributor submits a PR and the remote cache is not accessible
```
$ turbo run build
ERROR No caches are enabled. You can try "turbo login", "turbo link", or ensuring you are not passing --remote-only to enable caching: <nil>
• Packages in scope: @vercel/build-utils, @vercel/client, @vercel/frameworks, @vercel/go, @vercel/next, @vercel/node, @vercel/node-bridge, @vercel/python, @vercel/redwood, @vercel/remix, @vercel/routing-utils, @vercel/ruby, @vercel/static-build, @vercel/static-config, vercel
```
```ts
/*
Example 1:
my-repo
|-- packages
| |-- api-1
| |-- api-2
|-- package.json
|-- pnpm-workspaces.yaml // packages: ["packages/*"]
getWorkspaces("my-repo") => [
{
implementation: "pnpm",
rootPath: "https://github.com/.../my-repo"
}
]
Example 2:
my-repo
|-- backend
| |-- api-1
| |-- api-2
| |-- package.json // workspaces: ["api-1", "api-2"]
|-- frontend
| |-- nextjs-app
| |-- gatsby-app
| |-- package.json
| |-- pnpm-workspaces.yaml // packages: ["nextjs-app", "gatsby-app"]
getWorkspaces("my-repo") => [
{
implementation: "yarn",
rootPath: "https://github.com/.../my-repo/backend"
},
{
implementation: "pnpm",
rootPath: "https://github.com/.../my-repo/frontend"
}
]
*/
type Workspace = {
implementation: "yarn" | "npm" | "pnpm"
rootPath: string // the path to the root of the workspace
}
function getWorkspaces(fs: DetectorFilesystem): Workspace[]
```
### Related Issues
> Closes https://github.com/vercel/vercel/issues/7730
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
To support legacy Builders like `@frontity/now` which still depends on the old `@now/build-utils` package name, create a symlink to `@vercel/build-utils` to make import the package work transparently.
Depends on #7842 being merged first.
The `DevServer` class as it's currently implement is not really suitable for unit testing, since it calls `process.exit()` when shutting down the server. This causes Jest to exit prematurely, and prevents tests after these one from running. This was in fact hiding some failing tests. So these tests were ported over to be "Dev" suite tests which spawn a child process of `vc dev` rather than running them in-process, so that the `process.exit()` doesn't exit Jest.
### Related Issues
We were previously using a custom type in Next.js for the build result although there is an existing type for this in the build-utils package which we can centralize around.
x-ref: https://github.com/vercel/vercel/pull/7854#issuecomment-1133934764
### 📋 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
Node 12 is EOL and we're starting to reference packages that don't install on node lower than 14, such as nuxt@3 and remix. Let's update to 14 for now.
This will prevent the possibility of an infinite loop occurring when importing builders that throw a `MODULE_NOT_FOUND` error. Instead, we'll just try to import the builders, then run yarn if necessary, and then try to import the builders a second time when needed. If that fails then we'll throw the original error.
* Revert "Revert "[static-build] Support subset of Build Output API v2" (#7803)"
This reverts commit dfb6ef949b.
* more specific v2 detection
* use nuxt@3.0.0-rc.3 to make sure the incident is resolved
* set test timeout to see if this works in CI
* update CI node version to 14
* add node_modules because it was taking too long to install in CI
* remove timeout
* remove node modules
* remove the nuxt@3 dependency
* finish update to node 14
* blank yarn.lock
* revert node version update
* fix revert
* remove newline
This env var should normally come from the `.env` file that is created from `vc pull`, but let's just be extra sure and hard-code it directly in to `vc build` command as well.
SvelteKit `adapter-vercel` depends on this env var being set for its detection logic.
Specify the `useRuntimes` property for the "remix" framework
to use the `@vercel/remix` Builder.
The `ENABLE_FILE_SYSTEM_API` env var is no longer necessary so the
`vercel.json` file from the Remix template has also been deleted.
This file will mimic the structure of `vercel/frameworks/frameworks.ts` in the sense that it defines the list of supported monorepo managers. These are the ones were targeting for the initial launch,
- Turborepo
```ts
export const monorepoManagers = [
{
name: "Turborepo",
slug: "turbo",
detectors: {
every: [
{
path: 'turbo.json'
},
],
},
},
]
```
### Related Issues
> Closes https://github.com/vercel/vercel/issues/7757
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
Adds a new Builder for the Remix framework. This Builder has support for a few different configurations of Remix including the "just the basics" Remix server as well as the "vercel" server build target configuration. If the project does not have the `@remix-run/vercel` runtime adapter as a dependency in package.json then this Builder will implicitly add it when generating the SSR serverless function.
In a follow-up PR, we can make this Builder be used in the frameworks configuration so that it is executed when `remix` framework is selected for the project, and we can update the remix example template in this repo to no longer require the `ENABLE_FILE_SYSTEM_API` env var.
This PR adds the latest iteration of the `vc build` command which invokes the Builders that a Project depends on locally and serializes the output into the `.vercel/output` directory.
### Related Issues
x-ref: https://github.com/vercel/nft/releases/tag/0.19.0
### 📋 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
### Related Issues
Currently if you have a `package.json` with `type: 'module'` the launcher will fail to load as it is not using ESM and isn't using the `.cjs` extension. This corrects the extension per the below error message.
```sh
ReferenceError: exports is not defined in ES module scope
This file is being treated as an ES module because it has a '.js' file extension and '/var/task/package.json' contains "type": "module". To treat it as a CommonJS script, rename it to use the '.cjs' file extension.
```
x-ref: https://github.com/vercel/next.js/issues/36903
### 📋 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
* Migrate ava cli dev tests to jest
* remove outdated test
* update tests
* Update utils
* update stdio to fix stalling
* test stdio tests
* add debug logs
* more logs
* use strip ansi
* update
* add exit flag and fix next dev test
* update timeout for mac ci
* update cancel
* update cancel tests.yml -> test.yml
* update other ids -> names
* remove outdated test
* de-dupe scripts
* remove redwood dev test due to size
These two tests have been problematic on MacOS for a long time,
but now that we've re-introduced `@vercel/next` into this repo,
they've started to fail on Linux/Windows as well.
So the idea is to use the `devCommand` property so that
`@vercel/next` Builder doesn't get invoked at all.
Since the `devCommand` property was not yet being unit tested,
some logic in `vc build` needed to be adjusted in order to properly
shut down the dev command (via `tree-kill` module) when the
process was being stopped in order to cleanly shut down.
The `symlink` symlink wasn't being persisted through Turbo's cache,
so this test was failing. So move the symlink directly into the git repo
since there's no need to create it at build-time (git can store symlinks
just fine).
Additionally, the test itself was not testing that the symlink was indeed
re-created as a symlink from within the lambda environment (it actually
wasn't, due to the upload code not considering symlinks), so the test
has been updated to test for that as well.
When running `nuxi build` locally, you'll end up with a `.output` directory. This is not used to produce a vercel deployment and can cause confusion with Build Output API v2 (which also expects a `.output` directory). It's better to leave this ignored.
### Related Issues
This removes the secret for turbo team as it filters anywhere vercel is printed in the logs and it doesn't really need to be secret.
x-ref: https://github.com/vercel/vercel/runs/6496893033?check_suite_focus=true
### 📋 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
* [tests] Use `turbo` for unit tests
* .
* .
* Revert "."
This reverts commit 3d6204fef3fda3c7b4bf08955a186fe806d7c597.
* Add "src/util/constants.ts" to outputs
* .
* Add `@vercel/node-bridge` outputs
* .
* Mac and Windows
* .
* Node 14
* .
* .
* Add templates to CLI output
* Run only selected test files
* Add cross platform testing
* make test paths relative and have minimum per chunk
* add install arg
* update shell
* bump cache key
* use backslashes on windows
* pass tests as arg
* update script name
* update turbo config
* forward turbo args correctly
* dont use backslashes
* chunk integration tests instead
* update env
* separate static-build tests
* ensure unit test turbo cache is saved
* ensure turbo cache is saved for dev/cli
* fix cache key and update timeout
* Increase static-build unit test timeout
* Leverage turbo remote caching instead of actions/cache
* apply suggestions and test chunking itself
* update other ci jobs
* fix test collecting
Co-authored-by: Nathan Rajlich <n@n8.io>
This test was added several years ago, before the monorepo in https://github.com/vercel/vercel/pull/2812 but it was never working correctly due to the way zero config behaves differently than the test with `builds` in vercel.json
We can fix it in a follow up PR
Node.js 12 reached EOL April 2022 so its time to notify customers.
This PR will warn starting today and then error once the discontinue date is reached in a couple months.
### Related Issues
Fixes pnpm 7 support. Now uses a yarn installed version and drops an unnecessary check for node version.
### 📋 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
These frameworks (remix and solidstart) use the legacy file system api (v2) so they can't support Node.js 16.x so we change engines to pin to Node.js 14.x
I also added the missing `ENABLE_FILE_SYSTEM_API=1` env var to solidstart to match remix.
https://vercel.com/docs/file-system-api/v2
* Track source of getting decrypted environment variables
* Add source as a query param
* Revert lock file changes
* Change source from strings to type
* Differential between pull and env pull
In order to support various `fs` operations for monorepo detection, the team needs to add two new abstract functions to `DetectorFilesystem` in order to traverse down into children directories
* readdir
* chdir
```ts
interface Stat {
name: string
path: string
type: "file" | "dir"
}
export abstract class DetectorFilesystem {
...
/**
* Returns a list of Stat objects from the current working directory.
*
* @example
*
* const url = "https://github.com/vercel/front"
* const fs = new GitDetectorFilesystem(...) // based on url
*
* // calls "https://api.github.com/repos/vercel/front/contents" behind the scenes
* await fs.readdir() => [
* { name: "docs", path: "docs", type: "dir" },
* { name: "front", path: "front", type: "dir" },
* ...,
* { name: "package.json", path: "package.json", type: "file" },
* ]
*/
protected abstract _readdir(name: string): Promise<Stat[]>;
/**
* Changes the current directory to the specified path and returns a new instance of DetectorFilesystem.
*
* @example
*
* my-repo
* |-- backend
* | |-- api-1
* | |-- api-2
* | |-- package.json // workspaces: ["api-1", "api-2"]
* | |-- yarn.lock
* |-- frontend
* | |-- nextjs-app
* | |-- gatsby-app
* | |-- package.json
* | |-- pnpm-workspaces.yaml // packages: ["nextjs-app", "gatsby-app"]
*
* const fs = new (...) // based on "my-repo" as the root
* const backendFs = fs.chdir("backend")
* const frontendFs = fs.chdir("frontend")
*
* const backendWorkspaceManager = detectFramework({ fs: backendFs, frameworkList: workspaceManagers }) // "yarn"
* const frontendWorkspaceManager = detectFramework({ fs: frontendFs, frameworkList: workspaceManagers }) // "pnpm"
*/
protected abstract _chdir(name: string): DetectorFilesystem
...
}
```
### Related Issues
> Related to https://github.com/vercel/vercel/issues/7750
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
Adds support for `pnpm@7` using a similar lock file detection and path setting method that `npm@7` uses
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] Issue from task tracker has a link to this PR
This check prevents a user from creating a build output targeting one environment (like `preview`) and deploying targeting another environment (like `production`). It checks `.vercel/output/builds.json` for the `target` property to decide this. If that file is missing, the check is not run.
The "remix" magic package is no longer preferred by Remix,
so anyone who is using a modern template won't have it installed.
Checking for `remix.config.js` is safer detection logic.
Checks for `TTY` input to decide to handle the command or not. If the input is not TTY and the user did not pass the `--yes` option, the CLi will exit with the message:
> Command `vercel pull` requires confirmation. Use option "--yes" to confirm.
In order to support monorepo detection, we need to build out the list of supported workspace managers so that our helper functions and API endpoints can utilize the same `detectFramework` function / logic to detect a workspace manager for a given git repository.
### Related Issues
- Closes https://github.com/vercel/vercel/issues/7731
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
improves package manager auto detection so that when multiple lock files are found, the highest priority one is selected rather than defaulting to yarn.
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### Tests
- [x] 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
This PR does a few things:
- Changes the existing warning message for Python 3.6 to print a discontinue date
- Will automatically fail new Python 3.6 deployments created after that date
- Consolidates logic to make Python version selection work in a similar manner to Node.js version selection
- Changes tests from JS to TS
Supply light mode logos over the frameworks API to be consumed by front
### Related Issues
### 📋 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
- [x] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
When a framework that outputs Build Output API v3 specifies the `cache`
property in the `config.json` file then static-build will include those
files in the `prepareCache()` function result.
When using `vc deploy --prebuilt`, we need to check for an actual ".vercel/output" before attempting to deploy. This PR adds a a check for that. Now...
In a directory without `.vercel/output`:
```
$ vc deploy --prebuilt
Error! Option `--prebuilt` was used, but no prebuilt deploy found in ".vercel/output"
```
In a direcotry with `.vercel/output` (where I've not linked it yet):
```
$ vc deploy --prebuilt
? Set up and deploy “~/source/vercel/examples/build-output-api/serverless-function”? [Y/n]
```
When the `.vercel` directory does not exist and the env vars
(`VERCEL_PROJECT_ID`/`VERCEL_ORG_ID`) are used for project
linking, the `vercel pull` command was throwing an error:
```
$ VERCEL_PROJECT_ID=xxxxxxxx VERCEL_ORG_ID=xxxxxxxxxx vercel pull
Vercel CLI 24.1.1-canary.3 — https://vercel.com/feedback
Downloading "development" Environment Variables for Project t
Error! ENOENT: no such file or directory, open '/Code/t/.vercel/.env.development.local'
```
This PR adds the required changes to the CLI to support overridable `vercel.json` `projectSettings` values. This PR is linked with changes on the API side too.
- The core changes are in `packages/cli/src/commands/deploy/index.ts`
- An unused code path was removed from `packages/client/src/create-deployment.ts`, `packages/cli/src/util/deploy/process-deployment.ts` and `packages/cli/src/util/index.ts`.
This will only work for *existing* deployment (not *new* ones). This is implemented by checking the `status` of the deployment (is it linked or not). An error is thrown if the user attempts to send overrided settings to a new project.
A warning is outputted when overrided settings are discovered and shares what settings are being overridden.
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] Issue from task tracker has a link to this PR
This PR sets environment properly in `vc pull`. The system env vars were not respecting the target `--environment`.
Adds tests for related `vc env` logic.
Go 1.18 has been released, but I find that I can't deploy my project on Vercel when `go.mod` has `go 1.18` in it.
1.18 adds some very useful features. It would be very valuable for developers to have Vercel support 1.18.
### Related Issues
This ensures a content-type is always set inside of each part of the multi-part payload as it's needed for proper parsing. This also ensures non-200 status codes/headers are passed back separate when they differ so that they can be handled independently without assuming they all match.
x-ref: https://vercel.slack.com/archives/C03AYHB6MA9
x-ref: https://github.com/vercel/vercel/pull/7507
### 📋 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
* Add `turbo.json`
Ran `npx @turbo/codemod create-turbo-config` like the warnings have been telling us to.
* [tests] Bump `turbo` and allow `turbo.json` in `.vercelignore` (#7623)
Co-authored-by: Jared Palmer <jared@jaredpalmer.com>
Co-authored-by: Steven <steven@ceriously.com>
Follow-up to #7671. Since `runNpmInstall()` might now be de-duped, only
print "Installing dependencies..." when the dependencies are actually
being installed. This avoids printing the log message unnecessarily when
the command won't actually be run, and also removes some duplication in
the Builders' code.
Adds detection logic for a framework / build script outputting Build Output v3
format to the filesystem. In this case, `static-build` will simply stop processing
after the Build Command since deserialization happens in the build-container side
of things (this is different compared to the v1 output which gets handled in this
Builder. The reason for that is because the v3 output matches what `vc build`
outputs vs. v1 which is a different format).
Adds a best-effort optimization to only run `npm install` once per
`pacakge.json` file. This will save a lot of time in the single-sandbox
build world (i.e. `vc build`).
### Related Issues
Updates the @vercel/nft dependency across the repo to v0.18.1.
### 📋 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
The `prepareCache()` function was throwing an error when doing `vc deploy --prebuilt` because the `package.json` file is not present.
Also just cleaned up the logic a bit.
`repoRootPath` is provided to the `prepareCache()` function and is the same value as provided to the `build()` function.
Also remove `cachePath` since it's no longer used.
* refactor in prep for changes
* pull all target env files
* update `pull` usage
* move .env files into /.vercel
* tighten types in helper functions
* add return type
* remove "any" type
* keep original behavior
* only use --env for root-level env file name
* add --target flag
* deprecate --env for --env-file
* rename --target to --environment
* more renaming
* pr feedback
* update `vc pull --help`
* Update pull.ts
* remove env-file logic from `vc pull`
Co-authored-by: Steven <steven@ceriously.com>
`vc`'s default command is `deploy`, which can lead to ambiguous cli invocations when running `vc dir-or-command` like:
```
$ vc list
Vercel CLI 23.1.2
Error! The supplied argument "list" is ambiguous.
If you wish to deploy the subdirectory "list", first run "cd list".
```
when run in a directory that contains a subdirectory "list". This conflict will happen with any current and future commands, like `vc build`.
In order to make sure the CLI can be invoked either way, this PR deprecates the default behavior. Going forward, a user would see the following.
**Conflicting Command, Run Command**
```bash
$ vc list
# warning: Did you mean to deploy the subdirectory "list"? Use `vc --cwd list` instead.
# ... runs the `list` command
```
**Conflicting Command, Deploy Directory**
```bash
$ vc --cwd list
# ... deploy as normal
```
---
Card: https://linear.app/vercel/issue/BUI-33/prevent-ambiguous-vc-command-oror-dir
Working with @TooTallNate to update the Vercel Redwood builder,
in preparation for the Redwood 1.0 launch.
- Support for nested api functions in dist folder:
This is essentially a change to the glob to pick up functions 1 level deep in the dist folder. In prior version of Redwood, we had a workaround specific to Vercel that we would like to take out. See redwoodjs/redwood#4813.
- ZeroConfig redirects:
Redwood now generates a 200.html file on every build, which is the "fallback" page for when a html file cannot be matched with the path. This PR adds support for using this 200.html file, out of the box for Redwood projects on Vercel.
This is to make it easy for users to deploy a partly prerendered project - without having to mess with the vercel.json file.
Closes#7592.
Closes#7630.
`vc build` outputs to the root-level `.vercel` directory, so no need to consider `rootDirectory` of the Project Settings when collecting this file list.
.substr() is deprecated so we replace it with .slice() or substring() which aren't deprecated
Signed-off-by: Tobias Speicher <rootcommander@gmail.com>
Co-authored-by: Steven <steven@ceriously.com>
Add `pnpm` commands to framework `installCommand.placeholders` so that it appears in the UI.
Additionally, adds the `pnpm-lock.yaml` file to an ignore list like the other lock files.
`vc build` is going to re-use the `meta` object between Builder
invocations, to allow arbitrary state to be shared between them. So
allow for additional properties to be specified on `Meta` with an
`unknown` type.
* fix test 24 and add test 25
* move pnp/symlink test to cli and complete hoisted test
* fix execa
* remove unnecessary gitignore
* Update packages/cli/test/integration.js
Co-authored-by: Steven <steven@ceriously.com>
* Update packages/cli/test/integration.js
Co-authored-by: Steven <steven@ceriously.com>
* complete cherry-pick
* remove package.json edit
* use fs-extra remove
* use fs-extra.remove correctly
Co-authored-by: Steven <steven@ceriously.com>
In a previous PR (#4254), the behavior of `vercel dev` was added separately without matching how deployments work.
This PR consolidates the `tsconfig.json` options for `vercel` deployments as well as `vercel dev` so they work the same.
Fixes https://github.com/vercel/customer-issues/issues/349
* temp commit
* update test case
* check for build cache hit
* Update packages/build-utils/test/integration.test.ts
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: Steven <steven@ceriously.com>
When running this example using `pnpm`, the filesystem environment variable was causing issues.
This change removes the variable and the file since it no longer serves a purpose.
Deployment was tested using `pnpm`, `npm`, and `yarn` and all seem to run successfully now
### Related Issues
x-ref: https://github.com/vercel/next.js/pull/34935
### 📋 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
Fixes issue introduced by #7436 when using `vc dev`. Since the dev-server script now imports `@vercel/node-bridge` directly, instead of copying the relevant files into the package, the bridge needs to be a regular dependency otherwise the import will fail.
```
Error: Cannot find module '@vercel/node-bridge/launcher.js'
Require stack:
- /usr/local/lib/node_modules/vercel/node_modules/@vercel/node/dist/dev-server.js
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:902:15)
at Function.Module._load (internal/modules/cjs/loader.js:746:27)
at Module.require (internal/modules/cjs/loader.js:974:19)
at require (internal/modules/cjs/helpers.js:93:18)
at Object.<anonymous> (/usr/local/lib/node_modules/vercel/node_modules/@vercel/node/dist/dev-server.js:79:23)
at Module._compile (internal/modules/cjs/loader.js:1085:14)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)
at Module.load (internal/modules/cjs/loader.js:950:32)
at Function.Module._load (internal/modules/cjs/loader.js:790:12)
at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:76:12)
Error! `node api/hello.js` failed with exit code 1
```
* refactor and add test to changelog
* group changelog into areas
* remove revert and reverted commits from changelog
* make sure Revert commits that revert a commit in a previous changelog are not filtered
* run "yarn test" as part of "yarn test-unit"
* remove advanced syntax
* remove advanced syntax
* temp changelog
* remove temp changelog
* remove global jest config
* Delete symlink
* scope jest dir to just the test files we care about
Add support for `pnpm` as well as new fixtures for `pnpm` with and without workspaces
#### 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 && yarn test-integration-once`
#### 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
* docs: use meaningful word in contributing
I have changed the word `run` to `pass` in the Contributing Guidelines file inside `Verifying your change` documentation.
This provides a better understanding of how to run tests after every change.
* docs: remove `test` command run in local development
Remove guideline to test the code using `yarn test`, the test command does not exist in the project root but the build command automatically runs the tests.
* docs: add info about how tests are run
Add information about tests are run in this repo
* docs: fix testing scripts reference
Fixed some mistakes in the contributing readme
- Added `yarn test-unit` instead of `yarn test`
Co-authored-by: Steven <steven@ceriously.com>
Updates `@vercel/node` to utilize the `NodejsLambda` class so that it doesn't need to explicitly bundle in the launcher/bridge files into the build result. This reduces the complexity of the Builder and is a cleaner separation of concerns. The `helpers.test.ts` file has been moved to `@vercel/node-bridge` so it's being removed in this PR as well.
Adds formal type interfaces for Builders into `@vercel/build-utils`, and
updates the serverless functions runtimes to utilize them. This provides
type safety for the args/return values in i.e. the `build()` functions,
where previously they were not using any explicit return type.
When an instance of this class is returned in a Builder's `output`, it is a signal to the build system that it needs to add additional files to the final Lambda before creating the zip file.
* [cli] Remove initial iteration of `vc build` and Plugins
The `vercel build` command is being restructured, so we'll remove it for
now so that this initial iteration isn't included as part of the stable
CLI release.
* Update packages/cli/src/commands/init/init.ts
Co-authored-by: Steven <steven@ceriously.com>
* Remove more `.output` references
* Remove unnecessary space
* Fix test
* Remove vc dev middleware tests for now
Co-authored-by: Steven <steven@ceriously.com>
Makes the `Lambda` class itself just a reference of the files that are
needed to produce a zip file, and adds a `createZip()` function that
does the actual zip file creation. This will allow the zip file creation
to be done in the Vercel build container instead of directly in the
Builder itself.
* Adds `files` property to `Lambda` class
* Adds `createZip()` function to `Lambda` class
* Deprecates the `createLambda()` function
* Deprecates the `zipBuffer` property (only populated when `createLambda()` is used)
* Removes the private `FILES_SYMBOL` symbol, since `files` is the same thing
This PR adds a new `vercel bisect` command which is inspired by `git bisect`. This command takes two deployment URLs as its input (one "bad" deployment that exhibits a bug, and one "good" deployment where the bug does not occur) and steps through the deployments using a binary search. The command is useful for finding a deployment (and commit if the project is connected to a Git repo) where a bug has been introduced.
<img width="582" alt="Screen Shot 2022-01-26 at 12 46 29 PM" src="https://user-images.githubusercontent.com/71256/151244295-8e90c493-c45f-40b4-8e43-f39e7fcac262.png">
These integration tests have started consistently failing with
`ECONNRESET` errors and after some debugging it's been
difficult to point the finger at anything related to Vercel
infrastructure. So possibly it's related to GitHub actions infra
changes, but either way retrying seems to help.
* [ci] Add turborepo for faster builds
* Replace yarn run with turbo run
* Fix typo
* Add `@vercel/build-utils` as explicit dev dep
* Remove unused --clean argument
* Only turbo the "build" script, leave tests as-is
* Bump turbo to 1.0.13
* Add back test-unit
* Revert "Add back test-unit"
This reverts commit 469868c5c06f6c6f15da7ef0a440587d41419fd8.
This is following a similar pattern to Next.js workflows so that the publish step is skipped and reduces the time it takes GH Actions to run since we don't need to build to know that it should be skipped.
This ensures that using `vc deploy --prebuilt` will also upload any files that `.output/**/.nft.json` points to and also handle the Root Directory correctly since `vc build` emits `rootdir/.output`.
- Related to https://github.com/vercel/runtimes/issues/304.
### Related Issues
> Fixes#7086
> Related to #7086
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### 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
- [ ] Issue from task tracker has a link to this PR
We have identified that the `handler` for Lambdas does not support a dot-preceded path for Ruby, Python, and probably other languages, so we're adjusting the File System API to change `.output` inside the Lambda to something else, which requires version `2` of `functions-manifest.json`.
Furthermore, we're also bumping the `.nft.json` files to version `2`, which allows `output` to be relative to the NFT file itself, so that, inside the Lambda, the behavior mentioned at the top can be applied by the File System API.
As a nice side effect, this will also support nested API Routes, because it'll place all the dependencies next to every API Route, meaning that the launcher will have access to all of them (bundling multiple API Routes or Pages into the same Lambda currently doesn't work for non-Next.js anyways, because of https://github.com/vercel/runtimes/issues/305).
#### 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
Previously, CLI Plugins would try to mount the user-provided request handler (e.g. `api/test.rb`) at the same position inside the Lambda at which the launcher was located (e.g. `api/test.rb`), which would cause the launcher to be overwritten.
With this change, all the destination mounting points for NFT input files are becoming relative to the `.output/server/pages/api` directory instead of `.output/server/pages`, so they should no longer overwrite the launcher, and instead be loaded from the launcher, like normal.
This PR might have two problems:
- If imports in Ruby/Python/etc are relative to `cwd` and not the file from which the import is executed (which I doubt), this would fail.
- We might have to replace `api` with the exact sub folder of the API Route within `.output/server/pages/api` if the current change doesn't yet work for nested paths. Although that also means repeating all of the other dependencies (not just the user-provided request handler) in a different location for every single API Route.
The two above will be tested after this PR was merged, as there currently isn't a way to test `vercel-plugin-go`, `vercel-plugin-python`, and `vercel-plugin-ruby` without publishing a canary, because they don't bundle `@vercel/build-utils`, which was the package that was just updated.
#### 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
* Use correct Lambda handler for compiled languages
* Use the correct entrypoint
* Fixed the logic
* Perfected it
* Simpler code
* Update packages/build-utils/src/convert-runtime-to-plugin.ts
Co-authored-by: Andy <AndyBitz@users.noreply.github.com>
* Handle edge cases and simplify logic
* Fixed the logic yet again to work perfectly
* Normalize Page path
* Simplified everything
* Fixed the tests
Co-authored-by: Andy <AndyBitz@users.noreply.github.com>
* Corrected CLI Plugin output creation
* Wait for the linking to be done before removing anything
* Make it work
* Renamed variables
* Made everything work
* Removed debugging
* Fixed comment typos
* [cli] Support `next export` in `vercel build`
* Add debug line
* Remove unused import
* Ensure file is copied
* Return in `getNextExportStatus`
* Include dotNextDir
Co-authored-by: Steven <steven@ceriously.com>
### Related Issues
This fixes https://github.com/vercel/runtimes/issues/299.
#### 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
When contributing to this repository, please first discuss the change you wish to make via [GitHub Discussions](https://github.com/vercel/vercel/discussions/new) with the owners of this repository before submitting a Pull Request.
Please read our [code of conduct](CODE_OF_CONDUCT.md) and follow it in all your interactions with the project.
Please read our [Code of Conduct](CODE_OF_CONDUCT.md) and follow it in all your interactions with the project.
## Local development
This project is configured in a monorepo pattern where one repo contains multiple npm packages. Dependencies are installed and managed with `yarn`, not `npm` CLI.
This project is configured in a monorepo, where one repository contains multiple npm packages. Dependencies are installed and managed with `pnpm`, not `npm` CLI.
To get started, execute the following:
```
git clone https://github.com/vercel/vercel
yarn install
yarn bootstrap
yarn build
yarn lint
yarn test
cd vercel
corepack enable
pnpm install
pnpm bootstrap
pnpm build
pnpm lint
pnpm test-unit
```
Make sure all the tests pass before making changes.
## Verifying your change
### Running Vercel CLI Changes
Once you are done with your changes (we even suggest doing it along the way ), make sure all the test still run by running
You can use `pnpm dev` from the `cli` package to invoke Vercel CLI with local changes:
```
yarn build && yarn test
cd ./packages/cli
pnpm dev <cli-commands...>
```
See [CLI Local Development](../packages/cli#local-development) for more details.
## Verifying your change
Once you are done with your changes (we even suggest doing it along the way), make sure all the tests still pass by running:
```
pnpm test-unit
```
from the root of the project.
@@ -50,7 +63,7 @@ Unit tests are run locally with `jest` and execute quickly because they are test
Integration tests create deployments to your Vercel account using the `test` project name. After each test is deployed, the `probes` key is used to check if the response is the expected value. If the value doesn't match, you'll see a message explaining the difference. If the deployment failed to build, you'll see a more generic message like the following:
```
[Error: Fetched page https://test-8ashcdlew.now.sh/root.js does not contain hello Root!. Instead it contains An error occurred with this application.
[Error: Fetched page https://test-8ashcdlew.vercel.app/root.js does not contain hello Root!. Instead it contains An error occurred with this application.
NO_STATUS_CODE_FRO Response headers:
cache-control=s-maxage=0
@@ -64,7 +77,7 @@ Integration tests create deployments to your Vercel account using the `test` pro
x-now-trace=iad1]
```
In such cases you can visit the URL of the failed deployment and append `/_logs`so see the build error. In the case above, that would be https://test-8ashcdlew.now.sh/_logs
In such cases, you can visit the URL of the failed deployment and append `/_logs`to see the build error. In the case above, that would be https://test-8ashcdlew.vercel.app/_logs
The logs of this deployment will contain the actual error which may help you to understand what went wrong.
When you run this script, you'll see all imported files. If anything file is missing, the bug is in [@vercel/nft](https://github.com/vercel/nft) and not the Builder.
When you run this script, you'll see all the imported files. If anything file is missing, the bug is in [@vercel/nft](https://github.com/vercel/nft) and not the Builder.
## Deploy a Builder with existing project
Sometimes you want to test changes to a Builder against an existing project, maybe with `vercel dev` or an actual deployment. You can avoid publishing every Builder change to npm by uploading the Builder as a tarball.
Sometimes you want to test changes to a Builder against an existing project, maybe with `vercel dev` or actual deployment. You can avoid publishing every Builder change to npm by uploading the Builder as a tarball.
1. Change directory to the desired Builder `cd ./packages/node`
2. Run `yarn build` to compile typescript and other build steps
2. Run `pnpm build` to compile typescript and other build steps
3. Run `npm pack` to create a tarball file
4. Run `vercel *.tgz` to upload the tarball file and get a URL
5. Edit any existing `vercel.json` project and replace `use` with the URL
We do try to keep issues in this repository focused on the vercel command line and related code.
At this point we think that this issue is best handled by our friendly Vercel support team. They can be found by contacting them at: https://vercel.com/help#issues
If you think closing of this is a mistake, then please re-open this issue and we'll take another look :bow:
The following page is a reference for how to create a Runtime by implementing
the Runtime API interface.
the Runtime API interface. It's a way to add support for a new programming language to Vercel.
> Note: If you're the author of a web framework, please use the [Build Output API](https://vercel.com/docs/build-output-api/v3) instead to make your framework compatible with Vercel.
A Runtime is an npm module that implements the following interface:
@@ -9,7 +11,6 @@ A Runtime is an npm module that implements the following interface:
// Do calculations to generate a fingerprint based off the source code here…
return'fingerprint goes here';
}
```
### `prepareCache()`
An **optional** exported function that is executed after [`build()`](#build) is
@@ -134,7 +112,8 @@ export async function shouldServe(options: ShouldServeOptions) {
}
```
If this function is not defined, Vercel CLI will use the [default implementation](https://github.com/vercel/vercel/blob/52994bfe26c5f4f179bdb49783ee57ce19334631/packages/now-build-utils/src/should-serve.ts).
If this function is not defined, Vercel CLI will use the [default
@@ -208,7 +187,8 @@ If you need to share state between those steps, use the filesystem.
### Directory and Cache Lifecycle
When a new build is created, we pre-populate the `workPath` supplied to `analyze` with the results of the `prepareCache` step of the previous build.
When a new build is created, we pre-populate the `workPath` supplied to `analyze` with the results of the `prepareCache` step of the
previous build.
The `analyze` step can modify that directory, and it will not be re-created when it's supplied to `build` and `prepareCache`.
@@ -216,6 +196,77 @@ The `analyze` step can modify that directory, and it will not be re-created when
The env and secrets specified by the user as `build.env` are passed to the Runtime process. This means you can access user env via `process.env` in Node.js.
### Supporting Large Environment
We provide the ability to support more than 4KB of environment (up to 64KB) by way of
a Lambda runtime wrapper that is added to every Lambda function we create. These are
supported by many of the existing Lambda runtimes, but custom runtimes may require
additional work.
The following Lambda runtime families have built-in support for the runtime wrapper:
-`nodejs`
-`python` (>= 3.8)
-`ruby`
-`java11`
-`java8.al2` (not `java8`)
-`dotnetcore`
If a custom runtime is based on one of these Lambda runtimes, large environment
support will be available without further configuration. Custom runtimes based on
other Lambda runtimes, including those that provide the runtime via `provided` and
`provided.al2`, must implement runtime wrapper support and indicate it via the
`supportsWrapper` flag when calling [`createLambda`](<#createlambda()>).
To add support for runtime wrappers to a custom runtime, first check the value of the
`AWS_LAMBDA_EXEC_WRAPPER` environment variable in the bootstrap script. Its value is
the path to the wrapper executable.
The wrapper must be passed the path to the runtime as well as any parameters that the
runtime requires. This is most easily done in a small `bootstrap` script.
In this simple `bash` example, the runtime is called directly if
`AWS_LAMBDA_EXEC_WRAPPER` has no value, otherwise the wrapper is called with the
This is achieved by using `exec` in `bash` to replace the running process with the wrapper,
maintaining the same PID and environment.
Once support for runtime wrappers is included, ensure `supportsWrapper` is set to
`true` in the call to [`createLambda`](<#createlambda()>). This will inform the build
process to enable large environment support for this runtime.
### Utilities as peerDependencies
When you publish your Runtime to npm, make sure to not specify `@vercel/build-utils` (as seen below in the API definitions) as a dependency, but rather as part of `peerDependencies`.
@@ -323,20 +374,22 @@ This is a [class](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refere
-`handler: String` path to handler file and (optionally) a function name it exports
-`runtime: LambdaRuntime` the name of the lambda runtime
-`environment: Object` key-value map of handler-related (aside of those passed by user) environment variables
-`supportsWrapper: Boolean` set to true to indicate that Lambda runtime wrappers are supported by this runtime
### `LambdaRuntime`
This is an abstract enumeration type that is implemented by one of the following possible `String` values:
[](https://github.com/vercel/vercel/discussions)
Vercel is a platform for **static sites and frontend frameworks**, built to integrate with your headless content, commerce, or database.
## Vercel
We provide a **frictionless developer experience** to take care of the hard things: deploy instantly, scale automatically, and serve personalized content around the globe.
Vercel is the platform for frontend developers, providing the speed and reliability innovators need to create at the moment of inspiration.
We make it easy for frontend teams to **develop, preview, and ship**delightful user experiences, where performance is the default.
We enable teams to iterate quickly anddevelop, preview, and shipdelightful user experiences. Vercel has zero-configuration support for 35+ frontend frameworks and integrates with your headless content, commerce, or database of choice.
Get started by [Importing a Git Project](https://vercel.com/new) and use `git push` to deploy. Alternatively, you can [install Vercel CLI](https://vercel.com/cli).
## Deploy
Get started by [importing a project](https://vercel.com/new) or using the [Vercel CLI](https://vercel.com/cli). Then, `git push` to deploy.
## Documentation
For details on how to use Vercel, check out our [documentation](https://vercel.com/docs).
## Caught a Bug?
## Contributing
1. [Fork](https://help.github.com/articles/fork-a-repo/) this repository to your own GitHub account and then [clone](https://help.github.com/articles/cloning-a-repository/) it to your local device
2. Install dependencies with `yarn install`
3. Compile the code: `yarn build`
4. Link the package to the global module directory: `cd ./packages/cli && yarn link`
5. You can start using `vercel` anywhere inside the command line
This project uses [pnpm](https://pnpm.io/) to install dependencies and run scripts.
As always, you should use `yarn test-unit` to run the tests and see if your changes have broken anything.
You can use the `dev` script to run local changes as if you were invoking Vercel CLI. For example, `vercel deploy --cwd=/path/to/project` could be run with local changes with `pnpm dev deploy --cwd=/path/to/project`.
## How to Create a Release
See the [Contributing Guidelines](./.github/CONTRIBUTING.md) for more details.
If you have write access to this repository, you can read more about how to publish a release [here](https://github.com/vercel/vercel/wiki/Creating-a-Release).
When deploying this project, there was not a successful deployment into the `READY` state.
## How to Fix It
This is a generic error to catch problems in the deployment. The error is likely to vary depending on the deployment and the conditions at the time.
Try looking in the logs for information about the deployment and the failure, this could be done at (vercel.com)[https://vercel.com]. You can also use the `vc logs` command to display the build logs for the deployment.
This might not be a permanent error and retrying the deployment might also resolve it.
You ran `vercel dev` inside a project that contains a `vercel.json` file with `env` or `build.env` properties that use [Vercel Secrets](https://vercel.com/docs/v2/build-step#environment-variables).
You ran `vercel dev` inside a project that contains a `vercel.json` file with `env` or `build.env` properties that use [Vercel Secrets](https://vercel.com/docs/concepts/projects/environment-variables).
In order to use environment variables in your project locally that have values defined using the Vercel Secrets format (e.g. `@my-secret-value`), you will need to provide the value as an environment variable using a `.env`.
@@ -24,4 +24,4 @@ TEST=value
In the above example, `TEST` represents the name of the environment variable and `value` its value.
For more information on Environment Variables in development, [see the documentation](https://vercel.com/docs/v2/build-step#environment-variables).
For more information on Environment Variables in development, [see the documentation](https://vercel.com/docs/concepts/projects/environment-variables).
@@ -7,7 +7,7 @@ When legacy `routes` are added in `now.json` or `vercel.json`, they cause confli
#### Possible Ways to Fix It
Migrate from using legacy `routes` to the new `rewrites`, `redirects`, and `headers` configurations in your `now.json` or `vercel.json` file or leverage them directly in your `next.config.js` with the built-in [custom routes support](https://github.com/zeit/next.js/issues/9081)
Migrate from using legacy `routes` to the new `rewrites`, `redirects`, and `headers` configurations in your `now.json` or `vercel.json` file or leverage them directly in your `next.config.js` with the built-in [custom routes support](https://github.com/vercel/next.js/issues/9081)
You attempted to create a Vercel deployment where the input is a file, rather than a directory. Previously this was allowed, however this behavior has been removed as of Vercel CLI v24.0.0 because it exposed a potential security risk if the user accidentally created a deployment from a sensitive file.
#### Possible Ways to Fix It
- Run the `vercel deploy` command against a directory, instead of a file.
`@now/next` has two modes: `legacy` and `serverless`. You will always want to use the `serverless` mode. `legacy` is to provide backwards compatibility with previous `@now/next` versions.
`@vercel/next` has two modes: `legacy` and `serverless`. You will always want to use the `serverless` mode. `legacy` is to provide backwards compatibility with previous `@vercel/next` versions.
The differences:
@@ -27,7 +27,7 @@ Serverless:
- Runs `npm run now-build`
- Does not run `npm install --production` as the output from the build is all that's needed to bundle lambdas.
- No runtime dependencies, meaning smaller lambda functions
- Optimized for fast [cold start](https://vercel.com/blog/serverless-ssr#cold-start)
6. Make sure you have the correct Node.js version selected for your build step in your project settings (`https://vercel.com/[username]/[project]/settings`)
This is the public list of examples for **Vercel**.
All of these ready to deploy examples feature a frontend framework or static site, created with zero configuration using the CLI tools they provide.
The `+functions` examples feature an `/api` directory as well, highlighting how to use serverless functions on top of a framework, again with zero configuration required.
## What is Vercel?
Vercel is a cloud platform for static frontends and serverless functions. It enables developers to host websites and web applications that deploy instantly, scale automatically, and require no supervision.
## What Does this Repository Contain?
This repository consists of multiple examples, created for use with the [Vercel](https://vercel.com) platform. In addition to this, it also contains:
- [Code of Conduct](https://github.com/vercel/vercel/blob/master/.github/CODE_OF_CONDUCT.md) - our Code of Conduct, adapted from the [Contributor Covenant](http://contributor-covenant.org)
- [Contributing Guidelines](https://github.com/vercel/vercel/blob/master/.github/CONTRIBUTING.md) - a guide on how to contribute to the examples repository
- [License](https://github.com/vercel/vercel/blob/master/LICENSE) - the standard MIT license under which these examples are published
We recommend familiarizing yourself with the above sections, particularly if you are looking to make a contribution.
## Deploying Examples
To get started using any of these examples as your own project, [install Vercel](https://vercel.com/download) and use either of the following commands in your terminal:
To get started using any of these examples as your own project, [install Vercel](https://vercel.com/cli) and use either of the following commands in your terminal:
```sh
vercel init # Pick an example in the CLI
@@ -30,7 +8,7 @@ vercel init <example> # Create a new project from a specific <example>
vercel init <example> <name> # Create a new project from a specific <example> with a different folder <name>
```
Deploying your project takes seconds and can be done with **just a single command**:
Deploying your project can be done with **a single command**:
```sh
vercel # Deploy your project with the CLI
@@ -38,29 +16,9 @@ vercel # Deploy your project with the CLI
With the `vercel` command, your project will be built and served by Vercel, providing you with a URL that can be shared immediately.
## New Examples
We are continuously improving our examples based on best practices and feedback from the community. As a result, it is possible that example names will change and on occasion deprecated in favor of an improved implementation.
For example, the previous `nodejs` example showed a static frontend with a Node.js API. This is illustrated in the `svelte` example. Below is a table that lists some of the most popular previous examples and the equivalent replacement:
If you have an existing project you would like to deploy with Vercel, we recommend reading our guide on [migrating to Vercel and zero configuration](https://vercel.com/guides/migrate-to-vercel). By combining the guide with this repository, you will quickly be able to understand how to deploy your application.
If you would like to upgrade a project to take advantage of zero configuration, you may find the [upgrade guide](https://vercel.com/guides/upgrade-to-zero-configuration) useful. The upgrade guide covers how to remove configuration from existing projects along with how to use the `/api` directory.
## How to Contribute
Contributing examples should be an enjoyable experience, as such we have created a set of [contributing guidelines](https://github.com/vercel/vercel/blob/master/.github/CONTRIBUTING.md) to help you do so.
Contributing examples should be an enjoyable experience, as such we have created a set of [contributing guidelines](https://github.com/vercel/vercel/blob/main/.github/CONTRIBUTING.md) to help you do so.
The guidelines cover important information such as the requirements for new examples and where to get help if you have any questions.
@@ -74,10 +32,6 @@ An issue can be raised by clicking the 'Issues' tab at the top of the repository
When submitting an issue, please thoroughly and concisely describe the problem you are experiencing so that we may easily understand and resolve the issue in a timely manner.
## License
This repository is an open source project. See the [License](https://github.com/vercel/vercel/blob/master/LICENSE).
## Get In Touch
If you have any questions that are not covered by raising an issue then please get in touch with us on [GitHub Discussions](https://github.com/vercel/vercel/discussions). There you will find both members of the community and staff who are happy to help answer questions on anything Vercel related.
This directory is a brief example of an [AMP](https://amp.dev/) site that can be deployed with Vercel and zero configuration.
## Deploy Your Own
Deploy your own AMP project with Vercel.
[](https://vercel.com/new/clone?repository-url=https://github.com/vercel/vercel/tree/main/examples/amp)
_Live Example: https://amp.now-examples.now.sh_
### How We Created This Example
To get started deploying AMP with Vercel, you can use the [Vercel CLI](https://vercel.com/download) to initialize the project:
This directory is a brief example of an [Angular](https://angular.io/) app that can be deployed to Vercel with zero configuration.
This directory is a brief example of an [Angular](https://angular.io/) app that can be deployed with Vercel and zero configuration.
This project was generated with [Angular CLI](https://github.com/angular/angular-cli) version 13.1.3.
## Deploy Your Own
@@ -10,12 +10,28 @@ Deploy your own Angular project with Vercel.
[](https://vercel.com/new/clone?repository-url=https://github.com/vercel/vercel/tree/main/examples/angular&template=angular)
To get started with Angular, you can use the [Angular CLI](https://cli.angular.io/) to initialize the project:
Run `ng serve` for a dev server. Navigate to `http://localhost:4200/`. The application will automatically reload if you change any of the source files.
```shell
$ ng new
```
## Code scaffolding
Run `ng generate component component-name` to generate a new component. You can also use `ng generate directive|pipe|service|class|guard|interface|enum|module`.
## Build
Run `ng build` to build the project. The build artifacts will be stored in the `dist/` directory.
## Running unit tests
Run `ng test` to execute the unit tests via [Karma](https://karma-runner.github.io).
## Running end-to-end tests
Run `ng e2e` to execute the end-to-end tests via a platform of your choice. To use this command, you need to first add a package that implements end-to-end testing capabilities.
## Further help
To get more help on the Angular CLI use `ng help` or go check out the [Angular CLI Overview and Command Reference](https://angular.io/cli) page.
This directory is a brief example of an [Astro](https://astro.build/) site that can be deployed to Vercel with zero configuration.
## Deploy Your Own
Deploy your own Astro project with Vercel.
[](https://vercel.com/new/clone?repository-url=https://github.com/vercel/vercel/tree/main/examples/astro&template=astro)
_Live Example: https://astro-template.vercel.app_
## Project Structure
Inside of your Astro project, you'll see the following folders and files:
```
/
├── public/
│ └── favicon.ico
├── src/
│ ├── components/
│ │ └── Layout.astro
│ └── pages/
│ └── index.astro
└── package.json
```
Astro looks for `.astro` or `.md` files in the `src/pages/` directory. Each page is exposed as a route based on its file name.
There's nothing special about `src/components/`, but that's where we like to put any Astro/React/Vue/Svelte/Preact components or layouts.
Any static assets, like images, can be placed in the `public/` directory.
## Commands
All commands are run from the root of the project, from a terminal:
This directory is a brief example of a [Blitz.js](https://blitzjs.com/) project that can be deployed with Vercel and zero configuration.
This directory is a brief example of a [Blitz.js](https://blitzjs.com/) project that can be deployed to Vercel with zero configuration.
## Deploy Your Own
@@ -10,6 +8,8 @@ Deploy your own Blitz.js project with Vercel by viewing the [documentation on de
[](https://vercel.com/new/clone?repository-url=https://github.com/vercel/vercel/tree/main/examples/blitzjs&template=blitzjs)
_Live Example: https://blitz-template.vercel.app_
### How We Created This Example
To get started with Blitz.js, you can use [npx](https://www.npmjs.com/package/npx) to initialize the project:
This directory is a brief example of a [Brunch](https://brunch.io/) site that can be deployed with Vercel and zero configuration.
This directory is a brief example of a [Brunch](https://brunch.io/) site that can be deployed to Vercel with zero configuration.
## Deploy Your Own
@@ -8,7 +8,7 @@ Deploy your own Brunch project with Vercel.
[](https://vercel.com/new/clone?repository-url=https://github.com/vercel/vercel/tree/main/examples/brunch&template=brunch)
This directory is a brief example of a [React](https://reactjs.org/) app with [Serverless Functions](https://vercel.com/docs/v2/serverless-functions/introduction) that can be deployed with Vercel and zero configuration.
This directory is a brief example of a [Create React App](https://github.com/facebook/create-react-app) site that can be deployed to Vercel with zero configuration.
## Deploy Your Own
Deploy your own React project, along with Serverless Functions, with Vercel.
Deploy your own Create React App project with Vercel.
[](https://vercel.com/new/clone?repository-url=https://github.com/vercel/vercel/tree/main/examples/create-react-app-functions&template=create-react-app)
[](https://vercel.com/new/clone?repository-url=https://github.com/vercel/vercel/tree/main/examples/create-react-app&template=create-react-app)
To get started with React, along with [Serverless Functions](https://vercel.com/docs/v2/serverless-functions/introduction), with Vercel, you can use the [Create-React-App CLI](https://reactjs.org/docs/create-a-new-react-app.html#create-react-app) to initialize the project:
In the project directory, you can run:
```shell
$ npx create-react-app my-app
```
### `npm start`
Runs the app in the development mode. Open [http://localhost:3000](http://localhost:3000) to view it in your browser.
The page will reload when you make changes. You may also see any lint errors in the console.
### `npm test`
Launches the test runner in the interactive watch mode. See the section about [running tests](https://facebook.github.io/create-react-app/docs/running-tests) for more information.
### `npm run build`
Builds the app for production to the `build` folder.
It correctly bundles React in production mode and optimizes the build for the best performance. The build is minified and the filenames include the hashes.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
