This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.
# Releases
## vercel@33.0.0
### Major Changes
- [cli] replace `--deprecated` with `--update-required` in `vc project
ls` ([#10965](https://github.com/vercel/vercel/pull/10965))
### Patch Changes
- Fix `vercel bisect` selecting too many deployments
([#10956](https://github.com/vercel/vercel/pull/10956))
- Updated dependencies
\[[`6a9002f22`](6a9002f229),
[`4d63d9e95`](4d63d9e954)]:
- @vercel/remix-builder@2.0.15
- @vercel/build-utils@7.4.0
- @vercel/static-build@2.0.15
- @vercel/node@3.0.13
## @vercel/build-utils@7.4.0
### Minor Changes
- Adds new helper `getPathForPackageManager()`
([#10918](https://github.com/vercel/vercel/pull/10918))
## @vercel/client@13.0.11
### Patch Changes
- Updated dependencies
\[[`4d63d9e95`](4d63d9e954)]:
- @vercel/build-utils@7.4.0
## @vercel/gatsby-plugin-vercel-builder@2.0.13
### Patch Changes
- Add support for "rewrites"
([#10954](https://github.com/vercel/vercel/pull/10954))
- Updated dependencies
\[[`4d63d9e95`](4d63d9e954)]:
- @vercel/build-utils@7.4.0
## @vercel/node@3.0.13
### Patch Changes
- Updated dependencies
\[[`4d63d9e95`](4d63d9e954)]:
- @vercel/build-utils@7.4.0
## @vercel/remix-builder@2.0.15
### Patch Changes
- Update `@remix-run/dev` fork to v2.4.0
([#10943](https://github.com/vercel/vercel/pull/10943))
## @vercel/static-build@2.0.15
### Patch Changes
- Updated dependencies
\[[`652a31275`](652a312753)]:
- @vercel/gatsby-plugin-vercel-builder@2.0.13
## @vercel-internals/types@1.0.18
### Patch Changes
- Updated dependencies
\[[`4d63d9e95`](4d63d9e954)]:
- @vercel/build-utils@7.4.0
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
To use this outside of CLI we want a way to suppress the `console.log`s in `getEnvForPackageManager`.
For achieving this, we introduce a new helper `getPathForPackageManager()` which contains the core logic.
Best to review commit by commit + hide whitespace.
**X-Ref**
- [Internal Context](https://vercel.slack.com/archives/C03F2CMNGKG/p1701970097725689)
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.
# Releases
## vercel@32.7.1
### Patch Changes
- [cli] double page limit for vc project ls --deprecated
([#10932](https://github.com/vercel/vercel/pull/10932))
- Updated dependencies
\[[`d09dd1794`](d09dd1794b)]:
- @vercel/remix-builder@2.0.14
## @vercel/remix-builder@2.0.14
### Patch Changes
- Reinstall dependencies during `prepareCache()`
([#10922](https://github.com/vercel/vercel/pull/10922))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
As titled. Increases api page size for `vc project ls` when
`--deprecated` is used.
This is a temporary workaround since we do the filtering "client-side".
We will eventually update the API itself to support this and then we can
remove the client-based filter and reduce the page limit back to the
ideal `20`.
---------
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
https://github.com/vercel/vercel/pull/10819 introduced a bug causing the `prepareCache()` function to fail (due to `@remix-run/dev` no longer being require-able). Even if it were not failing, the deps installed are not a valid representation of the user's `package.json` / lockfile. So to have more truthful cache contents, run `npm install` once again during `prepareCache()` to fix both issues at the same time.
It seems the intention of this test was to verify that the rewritten
file matches the original file, but it does so by just asserting on
arbitrary script text, which is brittle and broke as a result of
https://github.com/vercel/next.js/pull/56294
The right way to test this would be to fetch the original script and
compare the contents with the rewritten script, but this relies on
`__NEXT_SCRIPT__` magic which is only available in probe checks. For now
this just asserts on a valid status code, as a chunk that isn't properly
rewritten should 404 in this case.
Adds a `--deprecated` option to the `vc project ls` command that will only show projects currently running on a soon-to-be-deprecated Node.js version.
It also adds additional output providing more information to the user about what versions and a link to our documentation so they can learn more.
Example:
<img width="836" alt="Screenshot 2023-12-07 at 15 01 22" src="https://github.com/vercel/vercel/assets/16144158/3b7f7b13-802e-4af1-a76e-a158a477beb4">
Fixes a neat little bug with the intersection of northstar users, teams, and the behavior of `Array#find_index`:
When selecting an org for various cli actions _non_ northstar users will see a select list with their user in the 0th position, and their teams in the 1..nth positions, like so:
```
// user: Logan
// teams: [Avengers, X-Men]
○ Logan
○ Avengers
○ X-Men
```
We'd like to preselect either a team referenced in `client.config.currentTeam` or if said team cannot be found in the collection of a user's teams, preselect the user. So if `X-Men` is `currentTeam`, we find that item (element `1` in the teams array) and increment that value by `1` to account for the user being element `0` in the list of choices:
```
// currentTeam: X-Men
// user: Logan
// teams: [Avengers, X-Men]
○ Logan
○ Avengers
● X-Men
```
If we _can't_ find the `currentTeam` in the list of teams (or one isn't provided), `Array#find_index` returns `-1`, which we increment to by `1` to get the 0th element in the list of choices:
```
// currentTeam: undefined
// user: Logan
// teams: [Avengers, X-Men]
● Logan
○ Avengers
○ X-Men
```
Neat trick!
However, Northstar users _don't_ use the user account as the 0th element in the list of choices. Northstar users will in fact have a team that represents a hidden default team with the same name as their `user.name` and this will be the 0th element in their teams:
```
// user: Logan
// teams: [Logan, Avengers, X-Men]
○ Logan
○ Avengers
○ X-Men
```
This of course means the trick of `+1` to index of the team selects the wrong item _and_ can result in `undefined` in cases where the `currentTeam` references the last team.
```
// currentTeam: X-Men
// user: Logan
// teams: [Logan, Avengers, X-Men]
○ Logan
○ Avengers
○ X-Men
```
● how'd we get out here?!?! 👀
To address the issue this PR:
1. calls `findIndex` on the array of _choices_ checking for matches to `currentTeam`
2. wraps that in `Math.max` to set to `0` if `find_index` returns `-1` when a `currentTeam` can't be found.
Tracking down a bug with "northstar" users and have a little prefactor that
a) isolates setup code so it's less repeated
b) makes the "northstar" tests more reflective of actual execution.
Northstar users will always have a `currentTeam` value on their `client.config`:
aa0f3d712b/packages/cli/src/util/get-scope.ts (L18-L20)
And finally c) add tests for the case of a non-northstar users where a team scope is supplied.
The final hypothetical matching group (northstart users with team scope provided) is the bug that I'll fix with a refactor.
User reported a scenario in which npm was ignoring the second `npm install` command to replace the Remix compiler with our forked version. This seems like a bug in npm. Workaround that seems to work is to remove `@remix-run/dev` entirely and install our forked version as a "standard" dependency (instead of using the `npm:` syntax). The `bin` entry for `remix` should at that point be our forked compiler.
`jsdom@23` does not work with Node 16, but UmiJS v2 does not work with Node 18. So use the lower common denominator and force a older version of jsdom that still works with 16.x.
`getSourceFilePathFromPage` attempts to match patterns found in `vercel.json` with source files. However, the `page` argument to this function is stripped of route groups, so these files are erroneously skipped and function settings are not applied.
For app-dir routes which might contain route groups, this checks an internal mapping which maps the "normalized" paths (e.g. `app/dashboard/[slug]/page.js`) to the file-system path (e.g. `app/dashboard/[slug]/(group)/page.js`)
CI started failing on corepack related tests with error:
```
error This project's package.json defines "packageManager": "yarn@npm@8.1.0". However the current global version of Yarn is 1.22.21.
```
This appears to be a bug in the Yarn v1.22.21, which was released a week ago: https://github.com/yarnpkg/yarn/releases/tag/v1.22.21
Setting the `SKIP_YARN_COREPACK_CHECK` env var disables this new check which fixes the issue for us.
**NOTE:** Review with [whitespace changes disabled](https://github.com/vercel/vercel/pull/10858/files?w=1) for an easier view.
This a small QOL change. Essentially if you have a tool like `fnm` on your machine for using multiple versions of Node.js, they will look for files like this one and automatically switch your terminal session node version to the value in it.
The `vercel/front` repo uses this too
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
# Releases
## @vercel/build-utils@7.2.4
### Patch Changes
- Select Node.js version based on what's available in build-container ([#10822](https://github.com/vercel/vercel/pull/10822))
## vercel@32.5.4
### Patch Changes
- Updated dependencies \[[`65dec5b7e`](65dec5b7e7)]:
- @vercel/build-utils@7.2.4
- @vercel/node@3.0.10
- @vercel/static-build@2.0.11
## @vercel/client@13.0.8
### Patch Changes
- Updated dependencies \[[`65dec5b7e`](65dec5b7e7)]:
- @vercel/build-utils@7.2.4
## @vercel/gatsby-plugin-vercel-builder@2.0.10
### Patch Changes
- Updated dependencies \[[`65dec5b7e`](65dec5b7e7)]:
- @vercel/build-utils@7.2.4
## @vercel/node@3.0.10
### Patch Changes
- Updated dependencies \[[`65dec5b7e`](65dec5b7e7)]:
- @vercel/build-utils@7.2.4
## @vercel/static-build@2.0.11
### Patch Changes
- Updated dependencies \[]:
- @vercel/gatsby-plugin-vercel-builder@2.0.10
## @vercel-internals/types@1.0.15
### Patch Changes
- Updated dependencies \[[`65dec5b7e`](65dec5b7e7)]:
- @vercel/build-utils@7.2.4
Makes `getLatestNodeVersion()` and `getSupportedNodeVersion()` (and thus by extension - `getNodeVersion()`) be aware of the available Node.js versions when running inside the build-container. This is to address the situation with the new AL2023 build-container image which has different Node versions installed compared to the existing AL2 build image.
### Project Settings `20.x` with package.json `"engines": "18.x"`
If the Project Settings Node Version is set to `20.x`, but the package.json has `"engines": "18.x"`, then the build will fail like so, because Node 18 is not present on the AL2023 build image:
<img width="1044" alt="Screenshot 2023-11-09 at 1 25 41 PM" src="https://github.com/vercel/vercel/assets/71256/572c544b-6574-4eb1-98f7-787075a60000">
### Project Settings `18.x` with package.json `"engines": "20.x"`
If the Project Settings Node Version is set to `18.x`, but the package.json has `"engines": "20.x"`, then the build will fail like so, because Node 20 is not present on the AL2 build image:
<img width="1042" alt="Screenshot 2023-11-09 at 1 34 43 PM" src="https://github.com/vercel/vercel/assets/71256/c6a2d955-9453-4ef5-a99d-b49a6d9af766">
### Project Settings `18.x` with no package.json `"engines"`
If Project Settings Node Version is set to `18.x`, but the package.json has no "engines" (and thus wants "latest"), then the latest available Node version in the build-container, which would be Node 18.
Not sure the best spot to put this command in the Readme, but I thought having a `create-remix` command might be useful for people trying to get going.
If there's a more preferred way to scaffold this project on your machine, I'm open to that, just using what I know
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.
# Releases
## vercel@32.5.3
### Patch Changes
- Handle `TooManyProjects` error in places where projects are created
([#10807](https://github.com/vercel/vercel/pull/10807))
- Updated dependencies
\[[`89c1e0323`](89c1e03233),
[`fd29b966d`](fd29b966d3)]:
- @vercel/node@3.0.9
- @vercel/next@4.0.14
## @vercel/next@4.0.14
### Patch Changes
- Fixed headers for static routes when PPR is enabled
([#10808](https://github.com/vercel/vercel/pull/10808))
## @vercel/node@3.0.9
### Patch Changes
- Replace usage of `fetch` with `undici.request`
([#10767](https://github.com/vercel/vercel/pull/10767))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
In a recent undici update, setting the `host` header for fetch requests became invalid (https://github.com/nodejs/undici/pull/2322).
We relied on this in order to proxy serverless dev server requests via `@vercel/node`.
This PR replaces the usage of `undici.fetch` with `undici.request`.
It is blocked by an `undici` type change: https://github.com/nodejs/undici/pull/2373
This PR adds improved error handling for the 200 project limit error
that will start being returned for free tier teams/accounts. The
following changes have been made:
- improve error message format by using `client.output.prettyError` so
that the docs link
(https://vercel.com/docs/limits/overview#general-limits) returned with
the error response is included with the error message
- add explicit error handling of this error from any places where
`createProject` is called, which includes the following commands:
- `vc project add`
- `vc link` (indirectly called via `ensureLink`)
- `vc list` (indirectly called via `ensureLink`)
- `vc git connect` (indirectly called via `ensureLink`)
### Testing
- sign in to a vercel account that is associated with your work email
(ends in `@vercel.com`), this is necessary for creating a team with the
proper conditions to artificially trigger the error message
- create a Pro Trial team and make sure to prefix the name with:
`vtest314 too many projects `, for example `vtest314 too many projects
test 1`
- check out this branch and cd to `vercel/vercel/packages/cli`
- run: `pnpm dev add [project-name] --cwd=/path/to/some/project`
- the project should fail to be created and you should see the expected
error message (screenshot below) in the terminal output
**Screenshot of error message when attempting to add project from cli**
<img width="798" alt="image"
src="https://github.com/vercel/vercel/assets/14896430/43e6ac2c-ae1c-4367-8d57-0aeb7fbddf33">
---------
Co-authored-by: Nathan Rajlich <n@n8.io>
This adds some tests to the PPR implementation for Next.js. This also
fixes a bug where the static pages were incorrectly generating a header
that falsly indicated that it postponed.
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.
# Releases
## vercel@32.5.2
### Patch Changes
- Updated dependencies
\[[`c94a082f6`](c94a082f6b)]:
- @vercel/next@4.0.13
## @vercel/next@4.0.13
### Patch Changes
- Added `getRequestHandlerWithMetadata` export
([#10753](https://github.com/vercel/vercel/pull/10753))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
This adds a new `getRequestHandlerWithMetadata` export if enabled and
available to the exported method.
---------
Co-authored-by: Joe Haddad <timer@vercel.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Our tests rely on not being behind deployment protection which is now enabled by default so this adds a step to tests to disable this setting to allow tests to continue working as expected.
When using `basePath` with statically generated routes, the builder
currently generates lambdas for the root route that conflict with the
prerender functions generated.
E.g. if we have `basePath: "test"` and a root route at: `app/page.js`,
this is currently the output:
```
test
test.rsc
test/index
test/index.rsc
```
The result is that visiting the deployed app at `/test` renders an
incomplete page. On the other hand visiting `/test/index` outputs the
expected markup.
It seems like the intent is that we want to delete the lambdas that
conflict with the prerender functions. I've updated the lambda name
generation logic when doing the deleting to line up with how the lambda
names are generated initially.
Follow-up to https://github.com/vercel/vercel/pull/10750 this removes the underscore prefetching from all prefetch outputs and instead only applies it to the index route itself as this causes issues with PPR making these outputs prerenders and being able to interpolate the route param values.
There is the edge case of a user returning the literal value `index` from `generateStaticParams` but we can tolerate that more than ppr not working as expected.
When `getUser(client)` throws an exception, the actual error is never printed. This is useful information, so we should write it to the debug log output.
This example occasionally fails with `ERROR: Command "yarn install"
exited with 1 at nowDeploy`. We've noticed errors at the yarn registry
being a root cause of lots of tests failures. This migrates the example
to use the npm registry instead.
Co-authored-by: Chris Barber <chris.barber@vercel.com>
Follow-up to https://github.com/vercel/vercel/pull/10734 -- but considers that the static prefetch associated with `/` might be inside of a dir such as `index/index.prefetch.rsc`.
To avoid any future matching conflicts, this PR updates to prefix all static prefetches
Fixes SSR / DSG pages that are nested deeper than the root path for Gatsby projects.
Also introduces unit tests for the logic related to determining which page name to use.
`next export` has been deprecated on the latest Next.js canary so these
tests will no longer pass.
This changes it to use `output: export` from `next.config.js` instead.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
# Releases
## vercel@32.5.0
### Minor Changes
- Indicates whether @vercel/speed-insights or @vercel/analytics are used ([#10623](https://github.com/vercel/vercel/pull/10623))
- [cli] update env var validation rule to allow name start with underscore ([#10697](https://github.com/vercel/vercel/pull/10697))
### Patch Changes
- Updated dependencies \[[`da300030c`](da300030c9), [`de84743e1`](de84743e10), [`913608de4`](913608de4d), [`7fa08088e`](7fa08088ea)]:
- @vercel/next@4.0.11
- @vercel/python@4.1.0
- @vercel/remix-builder@2.0.10
- @vercel/redwood@2.0.5
- @vercel/static-build@2.0.9
## @vercel/python@4.1.0
### Minor Changes
- Add support for pip3.10 and pip3.11 ([#10648](https://github.com/vercel/vercel/pull/10648))
## @vercel/routing-utils@3.1.0
### Minor Changes
- Adds support for statusCode property on rewrites ([#10495](https://github.com/vercel/vercel/pull/10495))
## @vercel/client@13.0.6
### Patch Changes
- Updated dependencies \[[`9e9fac019`](9e9fac0191)]:
- @vercel/routing-utils@3.1.0
## @vercel/fs-detectors@5.1.2
### Patch Changes
- Updated dependencies \[[`9e9fac019`](9e9fac0191)]:
- @vercel/routing-utils@3.1.0
## @vercel/gatsby-plugin-vercel-builder@2.0.8
### Patch Changes
- Updated dependencies \[[`9e9fac019`](9e9fac0191)]:
- @vercel/routing-utils@3.1.0
## @vercel/next@4.0.11
### Patch Changes
- fix `build` in appDir on Windows ([#10708](https://github.com/vercel/vercel/pull/10708))
- Fix RSC prefetch for index route with catch-all ([#10734](https://github.com/vercel/vercel/pull/10734))
## @vercel/redwood@2.0.5
### Patch Changes
- Updated dependencies \[[`9e9fac019`](9e9fac0191)]:
- @vercel/routing-utils@3.1.0
## @vercel/remix-builder@2.0.10
### Patch Changes
- Update `@remix-run/dev` fork to v2.1.0 ([#10732](https://github.com/vercel/vercel/pull/10732))
## @vercel/static-build@2.0.9
### Patch Changes
- Updated dependencies \[]:
- @vercel/gatsby-plugin-vercel-builder@2.0.8
## @vercel-internals/types@1.0.13
### Patch Changes
- Updated dependencies \[[`9e9fac019`](9e9fac0191)]:
- @vercel/routing-utils@3.1.0
Removes some old Gatsby tests and merge's their relevant probes into the newer `gatsby-v2` fixture.
No point having 3 separate Gatsby v2 tests when they can all be in one.
The `try to purchase a domain` CLI test starting failing on 11 October when the API became slightly slower to respond. This is because `vercel domains buy example.com` displays a prompt asking the user to `y` into agreeing to the purchase. We interacted with this in tests by spamming `y` on STDIN for a few seconds. The timing required is now a bit longer but I think we can skip that pattern entirely by passing the `--yes` option to the subcommand.
I don't _think_ we want this anywhere but in CI and let people unintentionally buy domains , so I've gated the use based on that, but happy to make it available always.
Ironically this issue went away on 13 October when the API response times improved and we could just unskip the test https://github.com/vercel/vercel/pull/10707
Allows to define a `statusCode` property on `rewrites` in the same way as we already have it for `redirects`.
This is still blocked internally as it requires a feature flag to build with that setting.
So it would allow to set the status in `vercel.json` like this:
```json
{
"rewrites": [
{
"source": "/*",
"destination": "not-found.html",
"statusCode": 404
}
]
}
```
Once released, I'll update the documentation on that as well.
### Requirements
> Cause once router sees a status code is set, it stops routing.
> So it wont run the `miss` and `rewrite` sections again once it has a status.
> So just need to make sure wherever status code is set, its at the end of its routing.
> [[internal ref](https://vercel.slack.com/archives/C01A2M9R8RZ/p1691594782351809?thread_ts=1691540814.244679&cid=C01A2M9R8RZ)]
I originally created with following the instructions on the site `npm create svelte@latest` but got confused seeing a version `5.1.1` but that's for `create-svelte`, not `svelte` itself. It creates a svelte 4 app still.
This adds a new `pnpm type-check` that leverages `turbo` to validate the TypeScript code. This can be run at the top-level or for an individual package.
The `test-lint` workflow will run it after linting and doing the prettier check.
As apart of this effort, each package's `tsconfig.json` has been simplified. There's a new top-level `tsconfig.base.json` file that extends the Vercel Style Guide for TypeScript. Each package's `tsconfig.json` has been audited and previously suppressed rules that no longer apply have been removed. The result is each package's `tsconfig.json` is greatly simplified and we can control common settings in the base config while keeping the flexibility of package-level overrides.
Lastly, in `package/cli`, `pnpm build` calls `scripts/build.mjs` which calls `scripts/compile-templates.mjs`. The `compile-templates.mjs` file was generating invalid TypeScript code. I've fixed it and now it's happier than ever.
Note: In order to run `pnpm type-check`, you must first `pnpm build` because we need the `.d.ts` definition files.
Auditing for options use of `testFixtureStdio`:
* `{ skipDeploy: true }` is used frequently.
* `{ readyTimeout: 2000 }` is used once in `'[vercel dev] 08-hugo'`
* `{ projectSettings: { directoryListing: true } }` is used once in `'[vercel dev] 00-list-directory'`
Both `isExample` and `expectedCode` have stopped being used.
Some of our tests take quite some time to run and occasionally timeout when accessing https://yarnpkg.com/. We decided to make sure there is a lockfile for this _and_ just move over to `npm`. Shifting the `packages/cli` fixtures over in this PR.
I possibly missed one but I changed the install commands in tests and ran
* pnpm test
* pnpm test-unit
* pnpm test-dev
* pnpm test-e2e
This reverts commit e9026c7a69.
This was causing some builds using Turbo + Next.js to fail with:
```
...writing to cache...
--
17:02:42.820 | Traced Next.js server files in: 169.874ms
17:02:42.871 | Error: Config file was not found at "/vercel/output/config.json"
17:02:42.871 | at f3 (/var/task/sandbox.js:239:2647)
17:02:42.872 | at async TCe (/var/task/sandbox.js:245:4681)
17:02:42.872 | at async WBt (/var/task/sandbox.js:261:1990)
17:02:42.872 | at async zBt (/var/task/sandbox.js:261:1791)
```
INC-442
There was a bug that we caught in the bundled server when using the instrumentation hook that we fixed in https://github.com/vercel/next.js/pull/56318 . This PR bumps the version that we check so that we don't use it if the Next version is not up to date.
While investigating build times noticed that our lambda creation times were increasing linearly with the number of pages which is unexpected since there are mostly shared dependencies. After further investigation it seems we were falling back to our legacy manual `nodeFileTrace` calls in the builder when we shouldn't have been.
Also noticed we were still doing the un-necessary reading/calculating for uncompressed lambda sizes which is as discussed previously isn't required and the only limit we need to keep enforcing is the uncompressed size which is a lot less expensive to compute.
As a further optimization this adds proper usage of our lstat cache/sema where it wasn't previously and proper parallelizing where applicable.
These changes reduce tracing/lambda creation times by 3-5x in larger applications and can fix edge cases where we weren't leveraging our more accurate traces from the build.
Before:
```sh
Traced Next.js server files in: 444.05ms
Created all serverless functions in: 1:36.311 (m:ss.mmm)
Collected static files (public/, static/, .next/static): 241.47ms
```
After:
```sh
Traced Next.js server files in: 10.4ms
Created all serverless functions in: 43.684s
Collected static files (public/, static/, .next/static): 250.828ms
```
As part of a refactor in #10535, we lost the – admittedly untested – behavior of
1. setting the new `teamId` from a login `result`
2. removing this value if it was `undefined` ensuring we didn't write `"currentTeam": undefined` to `config.json`.
This resulted in subsequent calls to `vc login` keeping the last known defined `teamId`.
This should restore that behavior but also retain the behavior of calling `updateCurrentTeamAfterLogin` to check if the user has a new `defaultTeamId` to be stored.
Not a fan of just how much mutation exists on `client.config` in this flow, but that predates this change and I wanted to keep this bugfix as small as possible.
This PR regenerates the ionic-angular and ionic-react fixtures to be significantly smaller and simpler.
I don't know why the lock files are so massive. If anyone has ideas to reduce the size of those (I've tried ripping out a bunch of dependencies).
Fixes a issue when a Next.js app uses app router + edge runtime + instrumentation hook deployed out on Vercel. The issue is that the code to register the instrumentation hook in Next.js expects `_ENTRIES` to be defined on `globalThis`.
```ts
async function registerInstrumentation() {
console.log("'_ENTRIES' in globalThis:", '_ENTRIES' in globalThis)
console.log(
'_ENTRIES.middleware_instrumentation:',
Boolean(_ENTRIES.middleware_instrumentation)
)
console.log(
'_ENTRIES.middleware_instrumentation.register:',
Boolean(_ENTRIES.middleware_instrumentation.register)
)
if (
'_ENTRIES' in globalThis &&
_ENTRIES.middleware_instrumentation &&
_ENTRIES.middleware_instrumentation.register
) {
try {
console.log('registering middleware instrumentation...')
await _ENTRIES.middleware_instrumentation.register()
console.log('registered middleware instrumentation!')
} catch (err: any) {
err.message = `An error occurred while loading instrumentation hook: ${err.message}`
console.error(err)
throw err
}
}
}
```
produced the following output,

This PR fixes this by changing `let _ENTRIES = {}'` to `globalThis._ENTRIES = {};`

Updates package manager detection to account for two lock files. All other managers will only have the one lock file. Bun, however, may have both a `bun.lockb` _and_ a `yarn.lock` file. To ensure bun is properly detected, the presence of `bun.lockb` with `yarn.lock` must occur before `yarn.lock` so we don't mistake the presence of a `yarn.lock` to mean "Yarn".
This PR also adds a test for this situation in `fs-detectors`. The behavior is currently correct there, but was not tested initially. It is now to avoid future regressions.
Reverts vercel/vercel#10570
This was causing a bug because my assumption about turbo cache hit/miss was incorrect.
I thought `turbo run test-e2e --listTests` would be use the same cache as `turbo run test-e2e` but it does not. So what was happening is that tests were not running on a second push to a PR because turbo already "cached" the result of `--listTests` so that `new-only` was saying there are no new tests and nothing to run 🤦
During [project-level-rbac bug bash](https://linear.app/vercel/issue/IAM-1267/vc-certs-ls-fails-with-typeerror-for-contributors) we were facing a runtime error
```
Error: An unexpected error occurred in certs: TypeError: Cannot read properties of undefined (reading 'length')
```
The reason for that is because the API responded with `403`, which was expected in our test. However the CLI should not exit with a generic runtime error in this case.
This PR removes the `.catch(err => err)` error shallowing instruction.
This PR removes a [deprecated package](https://www.npmjs.com/package/@zeit/source-map-support) that was originally added in PR https://github.com/vercel/vercel/pull/1205
The comment said:
```js
// we only enable source maps while developing, since
// they have a small performance hit. for this, we
// look for `pkg`, which is only present in the final bin
```
Some time along the way this was changed from development only, to always being installed.
However, no longer need this package because we can enable source maps for development by using [`--enable-source-map`](https://nodejs.org/docs/latest-v18.x/api/cli.html#--enable-source-maps) which has been available since Node.js 12
I noticed the latest release got [larger in size](https://packagephobia.com/result?p=vercel@32.3.1) when we were expecting it to get smaller.
This is because a 14MB source map was published to npm as [`dist/index.js.map`](https://unpkg.com/browse/vercel@32.3.1/dist/).
This PR disables source maps by default and you can optionally enable when running locally to debug.
This PR effectively reverts the change in https://github.com/vercel/vercel/pull/9172 since it is safe to skip tests that are not part of the turbo cache miss results. Previously, we were unable to do this because all of those jobs/checks were marked as required on the github repo settings. But now we have a single ["Summary" job](f6e863d4bb/.github/workflows/test.yml (L111-L128)) that is marked as required at the repo level so now we don't need to create jobs anymore just to see the turbo cache hit go green.
- [15f90b0](15f90b057d) correctly skipped all e2e tests since none of the packages changed
- [2613963](26139634fb) correctly ran the `vercel` e2e tests since the cli package was changed
- [8488b05](8488b0543b) correctly runs tests for all packages since build-utils was changed and all packages depend on it
Also see [Turbo `-output-logs` docs](https://turbo.build/repo/docs/reference/command-line-reference/run#--output-logs) for more.
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.
# Releases
## vercel@32.3.1
### Patch Changes
- Use "esbuild" to build CLI
([#10555](https://github.com/vercel/vercel/pull/10555))
- Updated dependencies
\[[`9f63ca60a`](9f63ca60ad),
[`e3f9faf51`](e3f9faf513)]:
- @vercel/next@4.0.8
- @vercel/remix-builder@2.0.8
## @vercel/next@4.0.8
### Patch Changes
- Fix edge case for setting `__NEXT_PRIVATE_PREBUNDLED_REACT`
([#10568](https://github.com/vercel/vercel/pull/10568))
## @vercel/remix-builder@2.0.8
### Patch Changes
- Update `@remix-run/dev` fork to v2.0.1
([#10566](https://github.com/vercel/vercel/pull/10566))
[](https://vercel.com/new/clone?repository-url=https://github.com/vercel/vercel/tree/main/examples/remix&template=remix)
- Remove Node.js v20 env var check ([#10834](https://github.com/vercel/vercel/pull/10834))
## 7.2.4
### Patch Changes
- Select Node.js version based on what's available in build-container ([#10822](https://github.com/vercel/vercel/pull/10822))
## 7.2.3
### Patch Changes
- Add experimental flag to allow Node.js v20 ([#10802](https://github.com/vercel/vercel/pull/10802))
## 7.2.2
### Patch Changes
- [cli] Update bun detection and add tests for projects with both bunlock binary and yarn.lock text files ([#10583](https://github.com/vercel/vercel/pull/10583))
'Found invalid Node.js Version: "18.x". Please set Node.js Version to 20.x in your Project Settings to use Node.js 20.'
);
});
it('should ignore node version in vercel dev getNodeVersion()',async()=>{
@@ -193,7 +215,7 @@ it('should warn when package.json engines is greater than', async () => {
{},
{}
)
).toHaveProperty('range','18.x');
).toHaveProperty('range','20.x');
expect(warningMessages).toStrictEqual([
'Warning: Detected "engines": { "node": ">=16" } in your `package.json` that will automatically upgrade when a new major Node.js Version is released. Learn More: http://vercel.link/node-version',
]);
@@ -232,7 +254,17 @@ it('should not warn when package.json engines matches project setting from confi
it('should throw for discontinued versions',async()=>{
@@ -300,14 +332,14 @@ it('should warn for deprecated versions, soon to be discontinued', async () => {
16
);
expect(warningMessages).toStrictEqual([
'Error: Node.js version 10.x has reached End-of-Life. Deployments created on or after 2021-04-20 will fail to build. Please set "engines": { "node": "18.x" } in your `package.json` file to use Node.js 18.',
'Error: Node.js version 10.x has reached End-of-Life. Deployments created on or after 2021-04-20 will fail to build. Please set Node.js Version to 18.x in your Project Settings to use Node.js 18.',
'Error: Node.js version 12.x has reached End-of-Life. Deployments created on or after 2022-10-03 will fail to build. Please set "engines": { "node": "18.x" } in your `package.json` file to use Node.js 18.',
'Error: Node.js version 12.x has reached End-of-Life. Deployments created on or after 2022-10-03 will fail to build. Please set Node.js Version to 18.x in your Project Settings to use Node.js 18.',
'Error: Node.js version 14.x has reached End-of-Life. Deployments created on or after 2023-08-15 will fail to build. Please set "engines": { "node": "18.x" } in your `package.json` file to use Node.js 18.',
'Error: Node.js version 14.x has reached End-of-Life. Deployments created on or after 2023-08-15 will fail to build. Please set Node.js Version to 18.x in your Project Settings to use Node.js 18.',
'Error: Node.js version 16.x has reached End-of-Life. Deployments created on or after 2024-02-06 will fail to build. Please set "engines": { "node": "18.x" } in your `package.json` file to use Node.js 18.',
'Error: Node.js version 16.x has reached End-of-Life. Deployments created on or after 2024-02-06 will fail to build. Please set Node.js Version to 18.x in your Project Settings to use Node.js 18.',
'Error: Node.js version 10.x has reached End-of-Life. Deployments created on or after 2021-04-20 will fail to build. Please set "engines": { "node": "20.x" } in your `package.json` file to use Node.js 20.',
'Error: Node.js version 10.x has reached End-of-Life. Deployments created on or after 2021-04-20 will fail to build. Please set Node.js Version to 20.x in your Project Settings to use Node.js 20.',
'Error: Node.js version 12.x has reached End-of-Life. Deployments created on or after 2022-10-03 will fail to build. Please set "engines": { "node": "20.x" } in your `package.json` file to use Node.js 20.',
'Error: Node.js version 12.x has reached End-of-Life. Deployments created on or after 2022-10-03 will fail to build. Please set Node.js Version to 20.x in your Project Settings to use Node.js 20.',
'Error: Node.js version 14.x has reached End-of-Life. Deployments created on or after 2023-08-15 will fail to build. Please set "engines": { "node": "20.x" } in your `package.json` file to use Node.js 20.',
'Error: Node.js version 14.x has reached End-of-Life. Deployments created on or after 2023-08-15 will fail to build. Please set Node.js Version to 20.x in your Project Settings to use Node.js 20.',
'Error: Node.js version 16.x has reached End-of-Life. Deployments created on or after 2024-02-06 will fail to build. Please set "engines": { "node": "20.x" } in your `package.json` file to use Node.js 20.',
'Error: Node.js version 16.x has reached End-of-Life. Deployments created on or after 2024-02-06 will fail to build. Please set Node.js Version to 20.x in your Project Settings to use Node.js 20.',
]);
global.Date.now=realDateNow;
@@ -541,6 +573,15 @@ it(
);
it('should return cliType bun and correct lock file for bun v1',async()=>{
- Revert "forbids globally installed @vercel/speed-insights and @vercel/analytics (#10848)" ([#10895](https://github.com/vercel/vercel/pull/10895))
## 32.6.0
### Minor Changes
- forbids globally installed @vercel/speed-insights and @vercel/analytics ([#10848](https://github.com/vercel/vercel/pull/10848))
### Patch Changes
- [cli] Fix behavior for combination of northstar user + team scope provided to cli as an argument. ([#10884](https://github.com/vercel/vercel/pull/10884))
"description":"The command-line interface for Vercel",
@@ -16,35 +16,37 @@
"test-e2e":"rimraf test/fixtures/integration && pnpm test test/integration-1.test.ts test/integration-2.test.ts test/integration-3.test.ts",
"test-dev":"pnpm test test/dev/",
"coverage":"codecov",
"build":"ts-node ./scripts/build.ts",
"dev":"ts-node ./src/index.ts"
"build":"node scripts/build.mjs",
"dev":"ts-node ./src/index.ts",
"type-check":"tsc --noEmit"
},
"bin":{
"vc":"./dist/index.js",
"vercel":"./dist/index.js"
},
"files":[
"dist",
"scripts/preinstall.js"
"dist"
],
"engines":{
"node":">= 16"
},
"dependencies":{
"@vercel/build-utils":"7.2.1",
"@vercel/go":"3.0.2",
"@vercel/build-utils":"7.4.0",
"@vercel/fun":"1.1.0",
"@vercel/go":"3.0.4",
"@vercel/hydrogen":"1.0.1",
"@vercel/next":"4.0.7",
"@vercel/node":"3.0.6",
"@vercel/python":"4.0.2",
"@vercel/redwood":"2.0.3",
"@vercel/remix-builder":"2.0.7",
"@vercel/ruby":"2.0.2",
"@vercel/static-build":"2.0.7"
"@vercel/next":"4.0.15",
"@vercel/node":"3.0.13",
"@vercel/python":"4.1.0",
"@vercel/redwood":"2.0.5",
"@vercel/remix-builder":"2.0.15",
"@vercel/ruby":"2.0.4",
"@vercel/static-build":"2.0.15",
"chokidar":"3.3.1"
},
"devDependencies":{
"@alex_neo/jest-expect-message":"1.0.5",
"@edge-runtime/node-utils":"2.2.1",
"@edge-runtime/node-utils":"2.2.2",
"@next/env":"11.1.2",
"@sentry/node":"5.5.0",
"@sindresorhus/slugify":"0.11.0",
@@ -86,15 +88,12 @@
"@types/yauzl-promise":"2.1.0",
"@vercel-internals/constants":"1.0.4",
"@vercel-internals/get-package-json":"1.0.0",
"@vercel-internals/types":"1.0.11",
"@vercel/client":"13.0.4",
"@vercel/error-utils":"2.0.1",
"@vercel/frameworks":"2.0.2",
"@vercel/fs-detectors":"5.1.0",
"@vercel/fun":"1.1.0",
"@vercel/ncc":"0.24.0",
"@vercel/routing-utils":"3.0.0",
"@zeit/source-map-support":"0.6.2",
"@vercel-internals/types":"1.0.18",
"@vercel/client":"13.0.11",
"@vercel/error-utils":"2.0.2",
"@vercel/frameworks":"2.0.5",
"@vercel/fs-detectors":"5.1.5",
"@vercel/routing-utils":"3.1.0",
"ajv":"6.12.2",
"alpha-sort":"2.0.1",
"ansi-escapes":"4.3.2",
@@ -106,10 +105,8 @@
"bytes":"3.0.0",
"chalk":"4.1.0",
"chance":"1.1.7",
"chokidar":"3.3.1",
"cli-table3":"0.6.3",
"codecov":"3.8.2",
"cpy":"7.2.0",
"date-fns":"1.29.0",
"debug":"3.1.0",
"dot":"1.1.3",
@@ -161,7 +158,6 @@
"strip-ansi":"6.0.1",
"supports-hyperlinks":"3.0.0",
"tar-fs":"1.16.3",
"test-listen":"1.1.0",
"text-table":"0.2.0",
"title":"3.4.1",
"tmp-promise":"1.0.3",
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.