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@8.1.1
### Patch Changes
- [build-utils] pnpm lockfile testing and fixing
([#11591](https://github.com/vercel/vercel/pull/11591))
## vercel@34.1.12
### Patch Changes
- Updated dependencies
\[[`67afc2608`](67afc26085),
[`2f7a6ed5f`](2f7a6ed5f9)]:
- @vercel/next@4.2.11
- @vercel/build-utils@8.1.1
- @vercel/node@3.1.2
- @vercel/static-build@2.5.6
## @vercel/client@13.2.4
### Patch Changes
- Updated dependencies
\[[`2f7a6ed5f`](2f7a6ed5f9)]:
- @vercel/build-utils@8.1.1
## @vercel/gatsby-plugin-vercel-builder@2.0.28
### Patch Changes
- Updated dependencies
\[[`2f7a6ed5f`](2f7a6ed5f9)]:
- @vercel/build-utils@8.1.1
## @vercel/next@4.2.11
### Patch Changes
- normalize source file locations for special metadata files
([#11579](https://github.com/vercel/vercel/pull/11579))
## @vercel/node@3.1.2
### Patch Changes
- Updated dependencies
\[[`2f7a6ed5f`](2f7a6ed5f9)]:
- @vercel/build-utils@8.1.1
## @vercel/static-build@2.5.6
### Patch Changes
- Updated dependencies \[]:
- @vercel/gatsby-plugin-vercel-builder@2.0.28
## @vercel-internals/types@1.0.33
### Patch Changes
- Updated dependencies
\[[`2f7a6ed5f`](2f7a6ed5f9)]:
- @vercel/build-utils@8.1.1
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Both `pnpm@6` and `pnpm@7` can parse lockfile versions `5.3` and `5.4`, but if there's a mismatch, `pnpm` will output a warning saying so. In order to prevent confusing warnings from being displayed to the user, this PR aligns the pnpm version with the exact lockfile verison.
It also adds a debug log to show which package manager version was determined based on the lockfile version.
When specifying a functions configuration in `vercel.json`, we attempt to find source files for all entrypoints. This attempts to normalize those source paths for some special cases so that we don't show a build warning for completely normal usage.
- `/_not-found` is an entrypoint automatically inserted by Next.js -- if we don't find a source file for it, don't warn, as the user might not have added one
- special metadata files like `favicon.ico` and `opengraph-image.<ext>` will be bundled as `favicon.ico/route.js` but the source file will be the raw extension.
The code we use to detect the version of `pnpm` based on lockfiles is hard to follow. It doesn't pick and executable, it instead of *sometimes* overrides the `PATH` for these utilities with a prepended alternate path.
This means that there is no one single place where we definitively specify which version of `pnpm` that is used, so much as *hope* that the `PATH` has the correct version on it. I don't know that we *can* specify an executable outside of the build container, and it's unclear, since this is a package, whether this utility is used outside of a build container setting.
In this pull request I cleaned up the code and updated the logic to include the `pnpm 7` and `pnpm 8` changes requested, with no changes yet to implement `pnpm 9`.
It's possible that we want to rewrite this detection logic from scratch to avoid this roundabout way of "finding" the executable, but I haven't done that here.
`@vercel/remix@2.9.2` is broken, but that's the version that tries to
get installed from the `^` caret. For now, explicitly use the
`2.9.2-patch.2` release which works correctly.
When rewriting requests that contain a `next-action` header to a `.action` output, we should do so only in the case where the RSC header isn't present. When a Next.js server action triggers a `redirect`, an intra-app RSC request will be made to that requested URL, with the `next-action` header still present. This means the intra-app request will be incorrectly rewritten, when we only intended to handle the actual action request.
This was patched in Next.js in the following PR:
- https://github.com/vercel/next.js/pull/65615
But it seems like a good idea to be resilient to this here as well.
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/functions@1.0.2
### Patch Changes
- Convert package to CommonJS
([#11569](https://github.com/vercel/vercel/pull/11569))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
The package was not working because it is using ESM syntax, but the
`package.json` did not have `"type": "module"`.
Anyways, for broader compatibility, let's use CommonJS.
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@34.1.10
### Patch Changes
- Updated dependencies
\[[`119f80e96`](119f80e961),
[`11584b0e9`](11584b0e9b),
[`3023122d4`](3023122d4e),
[`0e774b6be`](0e774b6be0)]:
- @vercel/next@4.2.9
- @vercel/static-build@2.5.4
## @vercel/next@4.2.9
### Patch Changes
- Support incremental partial prerendering
([#11560](https://github.com/vercel/vercel/pull/11560))
- ensure `.action` outputs are created for edge functions
([#11568](https://github.com/vercel/vercel/pull/11568))
- ([#11566](https://github.com/vercel/vercel/pull/11566))
## @vercel/static-build@2.5.4
### Patch Changes
- Fix `Cannot read properties of null` error
([#11559](https://github.com/vercel/vercel/pull/11559))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Since we're rewriting `next-action` requests to `.action` outputs, we need to ensure that we also duplicate the edge function handler for it.
This runs all of the existing Node runtime tests in the Edge runtime as well. However, there's a discrepancy in how `x-vercel-cache` is returned, so for now we instead validate that its responding with `x-edge-runtime`.
This fixes the logic that detects if partial prerendering (PPR) has been
enabled for a project. The new incremental adoption pathway allows
setting the `experimental.ppr = 'incremental'` which the previous code
did not support.
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/functions@1.0.1
### Patch Changes
- Don't throw error if context is missing
([`0817527f9`](0817527f9e))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
This PR makes `waitUntil` consistent when interacting with it via `vc
dev`. That includes:
**be possible to call `waitUntil` from the context second argument in
web handlers functions (Node.js & Edge)**:
```js
export function GET(request, { waitUntil }) {
waitUntil(fetch('https://vercel.com'));
return new Response('OK');
}
```
**be possible to call `waitUntil` imported from `@vercel/functions`**
(Node.js & Edge):
```js
import { waitUntil } from '@vercel/functions';
export function GET(request) {
waitUntil(fetch('https://vercel.com'));
return new Response('OK');
}
```
Additionally, `@vercel/functions` can be adopted for other framework to
take advantage of this pattern at Vercel.
---------
Co-authored-by: Javi Velasco <javier.velasco86@gmail.com>
While investigating https://github.com/vercel/next.js/issues/59883 we noticed the RSC Prerender did not have all the expected headers like the HTML Prerender which caused unexpected revalidation behavior specifically on client-transition as some of these headers are used to detect if a revalidated tag is associated with specific outputs.
x-ref: https://github.com/vercel/next.js/issues/59883
### Purpose of the Pull Request
This PR addresses a broken link in the README.md file that is supposed
to direct readers to the Code of Conduct. Previously, the link pointed
to `CODE_OF_CONDUCT.md`, which does not exist in the repository's main
directory. The corrected link points to the actual location of the file
in the `.github` directory.
### Changes Made
- Updated the link to the Code of Conduct from `[Code of
Conduct](CODE_OF_CONDUCT.md)` to `[Code of
Conduct](./.github/CODE_OF_CONDUCT.md)` to reflect the correct path.
### Additional Information
I previously opened discussion #11498 regarding this issue with the goal
of following the [Contribuing
Guidelines](https://github.com/vercel/vercel?tab=readme-ov-file#contributing),
but did not receive any feedback over the past week. Given the nature of
the change (a simple documentation fix), I proceeded with this pull
request to ensure the documentation remains useful and accurate for all
users.
### Impact
This change will help ensure that new contributors and users can easily
access the Code of Conduct, fostering better community interactions and
adherence to project standards.
Thank you for considering this pull request. I am open to any further
suggestions or requirements needed to merge this change.
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@34.1.8
### Patch Changes
- Updated dependencies
\[[`52e435aa5`](52e435aa5d),
[`124846a3e`](124846a3e6),
[`dc974b679`](dc974b6797),
[`58c6755e0`](58c6755e0c)]:
- @vercel/next@4.2.7
- @vercel/static-build@2.5.3
## @vercel/next@4.2.7
### Patch Changes
- Fix missing .rsc outputs for pages prerenders
([#11503](https://github.com/vercel/vercel/pull/11503))
- Fix base path app index RSC handling
([#11528](https://github.com/vercel/vercel/pull/11528))
- Fix interception routes PPR route handling
([#11527](https://github.com/vercel/vercel/pull/11527))
## @vercel/static-build@2.5.3
### Patch Changes
- Support Ruby and Python static site generators in AL2023 build image
([#11529](https://github.com/vercel/vercel/pull/11529))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
This ensures we properly name the outputs when a basePath is present for the `index` output as previously we weren't properly routing to the RSC output due to nested `index` naming/route conflict. This only was a noticeable issue with prerender/static index outputs with base path and app router since if the index route was dynamic it would still catch the RSC request and just handle it without the correct naming.
Fixes: https://github.com/vercel/next.js/issues/64903
* Set `GEM_HOME` env var based on the Ruby version in `$PATH` (i.e.
`3.2.0` for the AL2 build image, `3.3.0` for the AL2023 build image)
* Copy previous `jekyll-v4` test fixture to `jekyll-v4-al2` (uses AL2
build image)
* Update `jekyll-v4` test fixture to use Jekyll 4.3.3 (required for Ruby
3.3.0), and remove `package.json` so that it uses AL2023 build image
* Copy previous `middleman-v4` test fixture to `middleman-v4-al2` (uses
AL2 build image)
* Removed `package.json` from `middleman-v4` fixture, so that it uses
AL2023 build image
This ensures we properly create `.prefetch.rsc` output aliases for non-prerender outputs when PPR is enabled so that we can properly route which handles the interception route case as that is always dynamic so was missing it's `.prefetch.rsc` output causing the prefetch request to 404 unexpectedly.
x-ref: [slack thread](https://vercel.slack.com/archives/C070ZMMKVU7/p1714511126337289)
When generating the outputs for pages when app router is also present we weren't creating the placeholder `.rsc` outputs for all prerender outputs so when a `fallback: false` route was configured in the pages router that could fall through to an app route it causes issues with client-navigation behaving differently than a direct visit.
This ensures we add the placeholder `.rsc` outputs for all prerenders so that `fallback: false` pages don't have this unexpected behavior.
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@34.1.7
### Patch Changes
- Updated dependencies
\[[`3420ba015`](3420ba0153)]:
- @vercel/next@4.2.6
## @vercel/next@4.2.6
### Patch Changes
- [next] Update test fixture version
([#11514](https://github.com/vercel/vercel/pull/11514))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
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@34.1.6
### Patch Changes
- Updated dependencies
\[[`b1adaf76e`](b1adaf76ec),
[`3fb97d1d2`](3fb97d1d27)]:
- @vercel/next@4.2.5
- @vercel/static-build@2.5.2
## @vercel/next@4.2.5
### Patch Changes
- Only rewrite next-action requests to `.action` handlers
([#11504](https://github.com/vercel/vercel/pull/11504))
## @vercel/static-build@2.5.2
### Patch Changes
- Revert `SUPPORTED_RUBY_VERSION` change to fix Ruby site generators on
AL2 build image ([#11522](https://github.com/vercel/vercel/pull/11522))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
We accidentally committed a change which prevented the static-build e2e
tests, so fixing that.
Also reverting a change from https://github.com/vercel/vercel/pull/11497
which was causing issues with Ruby-based static site generators when
using the AL2 build image.
This only rewrites requests that contain a `next-action` header (explicitly indicating it's a server action). A side effect is that POST requests to a server action on a static route, without a next-action header, won't be marked as streaming (but will still execute normally). This is fine as only the handled action needs to stream.
This relands .action handling behind a feature flag.
Bumps the core group in /packages/static-build/test/fixtures/ionic-react-v7 with 4 updates: [react](https://github.com/facebook/react/tree/HEAD/packages/react), [@types/react](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/react), [react-dom](https://github.com/facebook/react/tree/HEAD/packages/react-dom) and [@types/react-dom](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/react-dom).
Updates `react` from 18.2.0 to 18.3.0
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a href="https://github.com/facebook/react/commits/HEAD/packages/react">compare view</a></li>
</ul>
</details>
<details>
<summary>Maintainer changes</summary>
<p>This version was pushed to npm by <a href="https://www.npmjs.com/~react-bot">react-bot</a>, a new releaser for react since your current version.</p>
</details>
<br />
Updates `@types/react` from 18.2.45 to 18.3.0
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a href="https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/react">compare view</a></li>
</ul>
</details>
<br />
Updates `react-dom` from 18.2.0 to 18.3.0
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a href="https://github.com/facebook/react/commits/HEAD/packages/react-dom">compare view</a></li>
</ul>
</details>
<details>
<summary>Maintainer changes</summary>
<p>This version was pushed to npm by <a href="https://www.npmjs.com/~react-bot">react-bot</a>, a new releaser for react-dom since your current version.</p>
</details>
<br />
Updates `@types/react-dom` from 18.2.17 to 18.3.0
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a href="https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/react-dom">compare view</a></li>
</ul>
</details>
<br />
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions
</details>
Bumps the core group in /packages/static-build/test/fixtures/astro-v4 with 1 update: [astro](https://github.com/withastro/astro/tree/HEAD/packages/astro).
Updates `astro` from 4.6.2 to 4.7.0
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/withastro/astro/releases">astro's releases</a>.</em></p>
<blockquote>
<h2>astro@4.7.0</h2>
<h3>Minor Changes</h3>
<ul>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10665">#10665</a> <a href="7b4f284020"><code>7b4f284</code></a> Thanks <a href="https://github.com/Princesseuh"><code>@Princesseuh</code></a>! - Adds new utilities to ease the creation of toolbar apps including <code>defineToolbarApp</code> to make it easier to define your toolbar app and <code>app</code> and <code>server</code> helpers for easier communication between the toolbar and the server. These new utilities abstract away some of the boilerplate code that is common in toolbar apps, and lower the barrier of entry for app authors.</p>
<p>For example, instead of creating an event listener for the <code>app-toggled</code> event and manually typing the value in the callback, you can now use the <code>onAppToggled</code> method. Additionally, communicating with the server does not require knowing any of the Vite APIs anymore, as a new <code>server</code> object is passed to the <code>init</code> function that contains easy to use methods for communicating with the server.</p>
<pre lang="diff"><code>import { defineToolbarApp } from "astro/toolbar";
<p>export default defineToolbarApp({
init(canvas, app, server) {</p>
<ul>
<li>app.addEventListener("app-toggled", (e) => {</li>
<li>
<pre><code> console.log(`App is now ${state ? &quot;enabled&quot; : &quot;disabled&quot;}`);.
</code></pre>
</li>
<li>});</li>
</ul>
<ul>
<li>app.onToggled(({ state }) => {</li>
<li>
<pre><code> console.log(`App is now ${state ? &quot;enabled&quot; : &quot;disabled&quot;}`);
</code></pre>
</li>
<li>});</li>
</ul>
<ul>
<li>if (import.meta.hot) {</li>
<li>
<pre><code> import.meta.hot.send(&quot;my-app:my-client-event&quot;, { message: &quot;world&quot; });
</code></pre>
</li>
<li>}</li>
</ul>
<ul>
<li>server.send("my-app:my-client-event", { message: "world" })</li>
</ul>
<ul>
<li>if (import.meta.hot) {</li>
<li>
<pre><code> import.meta.hot.on(&quot;my-server-event&quot;, (data: {message: string}) =&gt; {
</code></pre>
</li>
<li>
<pre><code> console.log(data.message);
</code></pre>
</li>
<li>
<pre><code> });
</code></pre>
</li>
<li>}</li>
</ul>
<ul>
<li>server.on<{ message: string }>("my-server-event", (data) => {</li>
<li>
<pre><code> console.log(data.message); // data is typed using the type parameter
</code></pre>
</li>
<li>});
},
})
</code></pre></li>
</ul>
<p>Server helpers are also available on the server side, for use in your integrations, through the new <code>toolbar</code> object:</p>
<pre lang="ts"><code>"astro:server:setup": ({ toolbar }) => {
toolbar.on<{ message: string }>("my-app:my-client-event", (data) => {
console.log(data.message);
toolbar.send("my-server-event", { message: "hello" });
});
}
</code></pre>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/withastro/astro/blob/main/packages/astro/CHANGELOG.md">astro's changelog</a>.</em></p>
<blockquote>
<h2>4.7.0</h2>
<h3>Minor Changes</h3>
<ul>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10665">#10665</a> <a href="7b4f284020"><code>7b4f284</code></a> Thanks <a href="https://github.com/Princesseuh"><code>@Princesseuh</code></a>! - Adds new utilities to ease the creation of toolbar apps including <code>defineToolbarApp</code> to make it easier to define your toolbar app and <code>app</code> and <code>server</code> helpers for easier communication between the toolbar and the server. These new utilities abstract away some of the boilerplate code that is common in toolbar apps, and lower the barrier of entry for app authors.</p>
<p>For example, instead of creating an event listener for the <code>app-toggled</code> event and manually typing the value in the callback, you can now use the <code>onAppToggled</code> method. Additionally, communicating with the server does not require knowing any of the Vite APIs anymore, as a new <code>server</code> object is passed to the <code>init</code> function that contains easy to use methods for communicating with the server.</p>
<pre lang="diff"><code>import { defineToolbarApp } from "astro/toolbar";
<p>export default defineToolbarApp({
init(canvas, app, server) {</p>
<ul>
<li>app.addEventListener("app-toggled", (e) => {</li>
<li>
<pre><code> console.log(`App is now ${state ? &quot;enabled&quot; : &quot;disabled&quot;}`);.
</code></pre>
</li>
<li>});</li>
</ul>
<ul>
<li>app.onToggled(({ state }) => {</li>
<li>
<pre><code> console.log(`App is now ${state ? &quot;enabled&quot; : &quot;disabled&quot;}`);
</code></pre>
</li>
<li>});</li>
</ul>
<ul>
<li>if (import.meta.hot) {</li>
<li>
<pre><code> import.meta.hot.send(&quot;my-app:my-client-event&quot;, { message: &quot;world&quot; });
</code></pre>
</li>
<li>}</li>
</ul>
<ul>
<li>server.send("my-app:my-client-event", { message: "world" })</li>
</ul>
<ul>
<li>if (import.meta.hot) {</li>
<li>
<pre><code> import.meta.hot.on(&quot;my-server-event&quot;, (data: {message: string}) =&gt; {
</code></pre>
</li>
<li>
<pre><code> console.log(data.message);
</code></pre>
</li>
<li>
<pre><code> });
</code></pre>
</li>
<li>}</li>
</ul>
<ul>
<li>server.on<{ message: string }>("my-server-event", (data) => {</li>
<li>
<pre><code> console.log(data.message); // data is typed using the type parameter
</code></pre>
</li>
<li>});
},
})
</code></pre></li>
</ul>
<p>Server helpers are also available on the server side, for use in your integrations, through the new <code>toolbar</code> object:</p>
<pre lang="ts"><code>"astro:server:setup": ({ toolbar }) => {
toolbar.on<{ message: string }>("my-app:my-client-event", (data) => {
console.log(data.message);
toolbar.send("my-server-event", { message: "hello" });
});
}
</code></pre>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="9876163406"><code>9876163</code></a> [ci] release (<a href="https://github.com/withastro/astro/tree/HEAD/packages/astro/issues/10865">#10865</a>)</li>
<li><a href="fc097e81a8"><code>fc097e8</code></a> [ci] format</li>
<li><a href="7b4f284020"><code>7b4f284</code></a> feat(toolbar): Toolbar API improvements (<a href="https://github.com/withastro/astro/tree/HEAD/packages/astro/issues/10665">#10665</a>)</li>
<li><a href="6fc4c0e420"><code>6fc4c0e</code></a> feat: add a new message telling the user that a new version of Astro is avail...</li>
<li><a href="43ead8fbd5"><code>43ead8f</code></a> Enable <code>allowJs</code> for <code>strictest.json</code> (<a href="https://github.com/withastro/astro/tree/HEAD/packages/astro/issues/10762">#10762</a>)</li>
<li><a href="8b59d5d078"><code>8b59d5d</code></a> Update sharp to 0.33 to fix issue with Alpine Linux (<a href="https://github.com/withastro/astro/tree/HEAD/packages/astro/issues/10684">#10684</a>)</li>
<li><a href="b673bc8505"><code>b673bc8</code></a> Fix an issue where <code>astro build</code> writes type declaration files to <code>outDir</code> (#...</li>
<li><a href="a94046588c"><code>a940465</code></a> [ci] release (<a href="https://github.com/withastro/astro/tree/HEAD/packages/astro/issues/10842">#10842</a>)</li>
<li><a href="9326531333"><code>9326531</code></a> [ci] format</li>
<li><a href="30cf82ac3e"><code>30cf82a</code></a> Prevents inputs from changing ViewTransitions' form method or action (<a href="https://github.com/withastro/astro/tree/HEAD/packages/astro/issues/10856">#10856</a>)</li>
<li>Additional commits viewable in <a href="https://github.com/withastro/astro/commits/astro@4.7.0/packages/astro">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions
</details>
Add support for ruby3.3 when using AL2023 (Node v20). No support for
ruby3.3 on Node <20 planned.
Ruby integration tests will now running on AL2023
---------
Co-authored-by: Nathan Rajlich <n@n8.io>
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@34.1.4
### Patch Changes
- Updated dependencies
\[[`5b7960337`](5b79603378)]:
- @vercel/next@4.2.4
## @vercel/next@4.2.4
### Patch Changes
- [next]: Revert .action handling for dynamic routes
([#11509](https://github.com/vercel/vercel/pull/11509))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Migrate `vc bisect` to updated argument parsing.
I added a `try` block with `handleError`, this seems to be in line with how we do this in other `vc` commands. It might be worth thinking about how we might abstract this logic to centralize it.
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@34.1.3
### Patch Changes
- Updated dependencies
\[[`5758838d0`](5758838d09)]:
- @vercel/next@4.2.3
## @vercel/next@4.2.3
### Patch Changes
- [next] Reland add .action handling for dynamic routes
([#11487](https://github.com/vercel/vercel/pull/11487))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Migrating `vc alias` to use new argument parsing utilities.
Note that our snapshot tests show that our help text was out of sync with what we were actually parsing from the user.
In particular, we were showing `-n` as the shorthand for both `next` and `limit` and neither of these had this shortflag. `next` was parsing `-N` (capital), so I've updated it to that.
`--json` was parsed, but wasn't mentioned in the help text. I've kept it this way, but it may be worth adding a description. We may want to have a separate discussion about the nature and role of `json` output from our CLI as a whole.
There aren't currently any tests for server actions which have special handling in the builder. This adds tests to help avoid regressions in future Next.js builder work.
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/python@4.2.0
### Minor Changes
- Add support for Python 3.12
([#11478](https://github.com/vercel/vercel/pull/11478))
## vercel@34.1.2
### Patch Changes
- Updated dependencies
\[[`64bd6dd05`](64bd6dd057),
[`532885148`](532885148b),
[`adcfc365a`](adcfc365a7)]:
- @vercel/next@4.2.2
- @vercel/python@4.2.0
## @vercel/next@4.2.2
### Patch Changes
- [next] revert .action rewrites
([#11470](https://github.com/vercel/vercel/pull/11470))
- Next.js builds: support sectioned source maps
([#11453](https://github.com/vercel/vercel/pull/11453))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Allows for `python3.12` to be used when the build is being run in the AL2023 build container (Node v20 project setting). This version is not usable in the AL2 image because `python3.12` is not installed there.
The e2e tests now default to running in AL2023, except for a few fixtures which require an older version of Python.
Turbopack outputs sectioned source maps, but webpack’s `webpack-sources`
packages doesn’t support these. For performance reasons, it should, but
as an interim solution, flatten these sections maps for compatibility.
---------
Co-authored-by: Nathan Rajlich <n@n8.io>
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.12.0
### Minor Changes
- Trigger release
([#11465](https://github.com/vercel/vercel/pull/11465))
## @vercel/static-build@2.5.0
### Minor Changes
- Don't rely on `hugo` binary existing in build-container
([#11455](https://github.com/vercel/vercel/pull/11455))
### Patch Changes
- Updated dependencies \[]:
- @vercel/gatsby-plugin-vercel-builder@2.0.25
## vercel@34.1.1
### Patch Changes
- Updated dependencies
\[[`f4c181a2c`](f4c181a2c2),
[`2826563ff`](2826563ffa)]:
- @vercel/static-build@2.5.0
- @vercel/build-utils@7.12.0
- @vercel/node@3.0.27
## @vercel/client@13.2.1
### Patch Changes
- Updated dependencies
\[[`2826563ff`](2826563ffa)]:
- @vercel/build-utils@7.12.0
## @vercel/gatsby-plugin-vercel-builder@2.0.25
### Patch Changes
- Updated dependencies
\[[`2826563ff`](2826563ffa)]:
- @vercel/build-utils@7.12.0
## @vercel/node@3.0.27
### Patch Changes
- Updated dependencies
\[[`2826563ff`](2826563ffa)]:
- @vercel/build-utils@7.12.0
## @vercel-internals/types@1.0.30
### Patch Changes
- Updated dependencies
\[[`2826563ff`](2826563ffa)]:
- @vercel/build-utils@7.12.0
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
PR #11305 didn't include this package as part of its changeset, so there
was no new release even though it is exporting a new function. Adding
this changeset so that the package is properly published.
Closes#11464.
* Makes `hugo` framework preset work when Node.js v20.x is selected in
Project Settings.
* Stores the downloaded `hugo` binary in the `.vercel/cache` directory,
so that it does not need to be re-downloaded upon every deployment.
* Makes `vc build` work when run locally for Hugo projects - tested on
macOS arm64.
This PR adds a rule to disallow the use of console.log/console.error/etc
from within the CLI package. The aim is to centralize our use of stdio
within the CLI so that everything moves through our client's output
module. It also disables the rule for all of the current console usage,
with the hopes that we will clean things up soon™
Also want to note that the rule only applies to usage from within the
CLI, so dependencies that the CLI pulls in (both external and even
within this monorepo) are unaffected.
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Bumps the core group in /packages/static-build/test/fixtures/astro-v4 with 1 update: [astro](https://github.com/withastro/astro/tree/HEAD/packages/astro).
Updates `astro` from 4.5.10 to 4.6.2
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/withastro/astro/releases">astro's releases</a>.</em></p>
<blockquote>
<h2>astro@4.6.2</h2>
<h3>Patch Changes</h3>
<ul>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10732">#10732</a> <a href="a92e263beb"><code>a92e263beb6e0166f1f13c97803d1861793e2a99</code></a> Thanks <a href="https://github.com/rishi-raj-jain"><code>@rishi-raj-jain</code></a>! - Correctly sets <code>build.assets</code> directory during <code>vite</code> config setup</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10776">#10776</a> <a href="1607face67"><code>1607face67051b16d4648555f1001b2a9308e377</code></a> Thanks <a href="https://github.com/fshafiee"><code>@fshafiee</code></a>! - Fixes cookies type inference</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10796">#10796</a> <a href="90669472df"><code>90669472df3a05b33f0de46fd2d039e3eba7f7dd</code></a> Thanks <a href="https://github.com/bluwy"><code>@bluwy</code></a>! - Disables streaming when rendering site with <code>output: "static"</code></p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10782">#10782</a> <a href="b0589d0553"><code>b0589d05538fcc77dd3c38198bf93f3548362cd8</code></a> Thanks <a href="https://github.com/nektro"><code>@nektro</code></a>! - Handles possible null value when calling <code>which-pm</code> during dynamic package installation</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10774">#10774</a> <a href="308b5d8c12"><code>308b5d8c122f44e7724bb2f3ad3aa5c43a83e584</code></a> Thanks <a href="https://github.com/Princesseuh"><code>@Princesseuh</code></a>! - Fixes <code>astro add</code> sometimes modifying <code>baseUrl</code> unintentionally</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10783">#10783</a> <a href="4dbd545304"><code>4dbd545304d1a8af903c8c97f237eb55c988c40b</code></a> Thanks <a href="https://github.com/jurajkapsz"><code>@jurajkapsz</code></a>! - Fixes Picture component specialFormatsFallback fallback check</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10775">#10775</a> <a href="0684312145"><code>06843121450899ecf0390ca4efaff6c9a6fe0f75</code></a> Thanks <a href="https://github.com/Princesseuh"><code>@Princesseuh</code></a>! - Fixes assets endpoint in serverless returning 404 in certain situations where the website might be under a protected route</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10787">#10787</a> <a href="699f4559a2"><code>699f4559a279b374bddb3e5e48c72afe2709e8e7</code></a> Thanks <a href="https://github.com/martrapp"><code>@martrapp</code></a>! - Fixes a timing issue in the view transition simulation.</p>
</li>
</ul>
<h2>astro@4.6.1</h2>
<h3>Patch Changes</h3>
<ul>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10708">#10708</a> <a href="742866c566"><code>742866c5669a2be4f8b5a4c861cadb933c381415</code></a> Thanks <a href="https://github.com/horo-fox"><code>@horo-fox</code></a>! - Limits parallel imports within <code>getCollection()</code> to prevent EMFILE errors when accessing files</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10755">#10755</a> <a href="c6d59b6fb7"><code>c6d59b6fb7db20af957a8706c8159c50619235ef</code></a> Thanks <a href="https://github.com/ematipico"><code>@ematipico</code></a>! - Fixes a case where the i18n fallback failed to correctly redirect to the index page with SSR enabled</p>
</li>
</ul>
<h2>astro@4.6.0</h2>
<h3>Minor Changes</h3>
<ul>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10591">#10591</a> <a href="39988ef8e2"><code>39988ef8e2c4c4888543c973e06d9b9939e4ac95</code></a> Thanks <a href="https://github.com/mingjunlu"><code>@mingjunlu</code></a>! - Adds a new dev toolbar settings option to change the horizontal placement of the dev toolbar on your screen: bottom left, bottom center, or bottom right.</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10689">#10689</a> <a href="683d51a5ee"><code>683d51a5eecafbbfbfed3910a3f1fbf0b3531b99</code></a> Thanks <a href="https://github.com/ematipico"><code>@ematipico</code></a>! - Deprecate support for versions of Node.js older than <code>v18.17.1</code> for Node.js 18, older than <code>v20.0.3</code> for Node.js 20, and the complete Node.js v19 release line.</p>
<p>This change is in line with Astro's <a href="https://docs.astro.build/en/upgrade-astro/#support">Node.js support policy</a>.</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10678">#10678</a> <a href="2e53b5fff6"><code>2e53b5fff6d292b7acdf8c30a6ecf5e5696846a1</code></a> Thanks <a href="https://github.com/ematipico"><code>@ematipico</code></a>! - Adds a new experimental security option to prevent <a href="https://owasp.org/www-community/attacks/csrf">Cross-Site Request Forgery (CSRF) attacks</a>. This feature is available only for pages rendered on demand:</p>
<pre lang="js"><code>import { defineConfig } from 'astro/config';
export default defineConfig({
experimental: {
security: {
csrfProtection: {
origin: true,
},
},
},
});
</code></pre>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/withastro/astro/blob/main/packages/astro/CHANGELOG.md">astro's changelog</a>.</em></p>
<blockquote>
<h2>4.6.2</h2>
<h3>Patch Changes</h3>
<ul>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10732">#10732</a> <a href="a92e263beb"><code>a92e263beb6e0166f1f13c97803d1861793e2a99</code></a> Thanks <a href="https://github.com/rishi-raj-jain"><code>@rishi-raj-jain</code></a>! - Correctly sets <code>build.assets</code> directory during <code>vite</code> config setup</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10776">#10776</a> <a href="1607face67"><code>1607face67051b16d4648555f1001b2a9308e377</code></a> Thanks <a href="https://github.com/fshafiee"><code>@fshafiee</code></a>! - Fixes cookies type inference</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10796">#10796</a> <a href="90669472df"><code>90669472df3a05b33f0de46fd2d039e3eba7f7dd</code></a> Thanks <a href="https://github.com/bluwy"><code>@bluwy</code></a>! - Disables streaming when rendering site with <code>output: "static"</code></p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10782">#10782</a> <a href="b0589d0553"><code>b0589d05538fcc77dd3c38198bf93f3548362cd8</code></a> Thanks <a href="https://github.com/nektro"><code>@nektro</code></a>! - Handles possible null value when calling <code>which-pm</code> during dynamic package installation</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10774">#10774</a> <a href="308b5d8c12"><code>308b5d8c122f44e7724bb2f3ad3aa5c43a83e584</code></a> Thanks <a href="https://github.com/Princesseuh"><code>@Princesseuh</code></a>! - Fixes <code>astro add</code> sometimes modifying <code>baseUrl</code> unintentionally</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10783">#10783</a> <a href="4dbd545304"><code>4dbd545304d1a8af903c8c97f237eb55c988c40b</code></a> Thanks <a href="https://github.com/jurajkapsz"><code>@jurajkapsz</code></a>! - Fixes Picture component specialFormatsFallback fallback check</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10775">#10775</a> <a href="0684312145"><code>06843121450899ecf0390ca4efaff6c9a6fe0f75</code></a> Thanks <a href="https://github.com/Princesseuh"><code>@Princesseuh</code></a>! - Fixes assets endpoint in serverless returning 404 in certain situations where the website might be under a protected route</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10787">#10787</a> <a href="699f4559a2"><code>699f4559a279b374bddb3e5e48c72afe2709e8e7</code></a> Thanks <a href="https://github.com/martrapp"><code>@martrapp</code></a>! - Fixes a timing issue in the view transition simulation.</p>
</li>
</ul>
<h2>4.6.1</h2>
<h3>Patch Changes</h3>
<ul>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10708">#10708</a> <a href="742866c566"><code>742866c5669a2be4f8b5a4c861cadb933c381415</code></a> Thanks <a href="https://github.com/horo-fox"><code>@horo-fox</code></a>! - Limits parallel imports within <code>getCollection()</code> to prevent EMFILE errors when accessing files</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10755">#10755</a> <a href="c6d59b6fb7"><code>c6d59b6fb7db20af957a8706c8159c50619235ef</code></a> Thanks <a href="https://github.com/ematipico"><code>@ematipico</code></a>! - Fixes a case where the i18n fallback failed to correctly redirect to the index page with SSR enabled</p>
</li>
</ul>
<h2>4.6.0</h2>
<h3>Minor Changes</h3>
<ul>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10591">#10591</a> <a href="39988ef8e2"><code>39988ef8e2c4c4888543c973e06d9b9939e4ac95</code></a> Thanks <a href="https://github.com/mingjunlu"><code>@mingjunlu</code></a>! - Adds a new dev toolbar settings option to change the horizontal placement of the dev toolbar on your screen: bottom left, bottom center, or bottom right.</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10689">#10689</a> <a href="683d51a5ee"><code>683d51a5eecafbbfbfed3910a3f1fbf0b3531b99</code></a> Thanks <a href="https://github.com/ematipico"><code>@ematipico</code></a>! - Deprecate support for versions of Node.js older than <code>v18.17.1</code> for Node.js 18, older than <code>v20.0.3</code> for Node.js 20, and the complete Node.js v19 release line.</p>
<p>This change is in line with Astro's <a href="https://docs.astro.build/en/upgrade-astro/#support">Node.js support policy</a>.</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10678">#10678</a> <a href="2e53b5fff6"><code>2e53b5fff6d292b7acdf8c30a6ecf5e5696846a1</code></a> Thanks <a href="https://github.com/ematipico"><code>@ematipico</code></a>! - Adds a new experimental security option to prevent <a href="https://owasp.org/www-community/attacks/csrf">Cross-Site Request Forgery (CSRF) attacks</a>. This feature is available only for pages rendered on demand:</p>
<pre lang="js"><code>import { defineConfig } from 'astro/config';
export default defineConfig({
experimental: {
security: {
csrfProtection: {
origin: true,
},
},
},
</code></pre>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="668d97319c"><code>668d973</code></a> [ci] release (<a href="https://github.com/withastro/astro/tree/HEAD/packages/astro/issues/10777">#10777</a>)</li>
<li><a href="a92e263beb"><code>a92e263</code></a> fix: use assetsDir in creating vite config (<a href="https://github.com/withastro/astro/tree/HEAD/packages/astro/issues/10732">#10732</a>)</li>
<li><a href="90669472df"><code>9066947</code></a> Disable streaming for SSG (<a href="https://github.com/withastro/astro/tree/HEAD/packages/astro/issues/10796">#10796</a>)</li>
<li><a href="b0589d0553"><code>b0589d0</code></a> astro/cli/install-package.ts: whichPm may return null if ran in an empty dire...</li>
<li><a href="af1af9faee"><code>af1af9f</code></a> [ci] format</li>
<li><a href="0684312145"><code>0684312</code></a> fix(assets): Forward headers from the original request to the internal reques...</li>
<li><a href="01cb41763e"><code>01cb417</code></a> [ci] format</li>
<li><a href="699f4559a2"><code>699f455</code></a> Make viewTransition.finished wait for animations triggered by viewTransition....</li>
<li><a href="1607face67"><code>1607fac</code></a> Fix <code>@types/cookie</code> dependency (<a href="https://github.com/withastro/astro/tree/HEAD/packages/astro/issues/10776">#10776</a>)</li>
<li><a href="4dbd545304"><code>4dbd545</code></a> fix: picture fallback check (<a href="https://github.com/withastro/astro/tree/HEAD/packages/astro/issues/10783">#10783</a>)</li>
<li>Additional commits viewable in <a href="https://github.com/withastro/astro/commits/astro@4.6.2/packages/astro">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions
</details>
Invoking an action that's a Prerender will currently bypass the static cache (via `experimentalBypassFor`), but the prerender group doesn't support streaming.
This clones the prerender group and adds corresponding rewrites for those requests. Separately, we'll deprecate `experimentalBypassFor`.
Depends on:
- https://github.com/vercel/next.js/pull/64592
In the past, we used the `VERCEL_ANALYTICS_ID` environment variable with the previous Speed Insights feature on Vercel to activate specific logic in Next.js, Nuxt and Gatsby for collecting and sending web vitals data.
With the new Speed Insights, that's not required anymore.
We no longer want to set the environment variable when detecting the new `@vercel/speed-insights` package.
This PR confirms that the variable is not set if the new package is detected.
The user's default team should be sorted to the top of the selector. This is a nice and simple way to do this, though I'm not sure how to test my changes -- would appreciate guidance!
`vc dev` in a dir without a `.git` dir would display an error the user should not see:
```
Vercel CLI 34.0.0
fatal: not a git repository (or any of the parent directories): .git
> Ready! Available at [http://localhost:3000](http://localhost:3000)
```
This fixes that by ignoring the stderr from `git rev-parse`.
Adds snapshot tests for the output from help as output by various commands. I expect to be changing some of the `Command` structs to continue the work started in [ [cli] Improve type signature of CommandOption #11394 ](https://github.com/vercel/vercel/pull/11394) especially as I build on work in [ Get flags specification #11433 ](https://github.com/vercel/vercel/pull/11433), and I want to be sure that the associated changes to help output are what we expect.
This ensures we properly include `_not-found` assets when present for
app router specific functions as otherwise when attempting to render
`notFound()` case we can hit `MODULE_NOT_FOUND` errors. A test case for
this behavior has been added under `00-app-router-not-found`.
Closes: [NEXT-3084](https://linear.app/vercel/issue/NEXT-3084)
Historically, we used to have a compressed function size limit of `50MB` but this is a very old limit and was removed long ago. Considering this limit is removed and it requires additional overhead to calculate, this removes the compressed size limit handling while leaving the uncompressed size limit detection/handling.
A customer was worried about security vulnerabilities that `pnpm audit` listed for `@babel/traverse`, `http-cache-semantics`, and `json5`. This updates those deps, removing those vulnerability messages.
The way that we currently parse arguments throughout the vercel command line is through the `getArgs` function. This function takes three arguments: `argv`, `argOptions`, and `argsOptions`. (Those last two arguments are swapped in order from the real function). This is semantically muddy and likely to create mistakes. We have instances in our code base, such as `deploy/index.ts` which at the time of this pull request creates a variable named `argOptions` and passes it to the `argsOptions` argument of `getArgs`.
Further, the return type of `arg` the library we currently use to parse arguments is unclear as well. It puts positional arguments under an `_` key, instead of a meaningful name.
In this pull request, I create a function called `parseArguments` that takes the same three arguments as `getArgs` with improved names: `args`, `flags`, and `parserOptions`. It also changes the return type to be an object with two keys: `{args, flags}` allowing for clearer access patterns where the argument parser is used.
The previous type signature of `CommandOption` did not cover all of the actual uses of option types throughout the codebase. This one may not cover all possible types, but comes much closer and allows us to literally state the type constructor used by `arg` to parse options.
This will allow for direct use of `command.ts` data structures so that Help output matches the actually parsed options used by every subcommand.
`deploy/index.ts` already shows an example of this, and a future pull request can build on that example by extracting that logic into a utility function.
We've done a pretty significant update over the past few months on
SolidStart and 1.0 is looming. Thought I'd update the official templates
to get in line before we do the release.
I wasn't sure what to do with the `output` fields as we use Vercel's
build output V3 here. But otherwise I think everything should be good.
---------
Co-authored-by: Nathan Rajlich <n@n8.io>
Co-authored-by: Jeff See <jeffsee.55@gmail.com>
We have several instances of `console.log` being used with colors or other indicators that they're trying to communicate to the user, and not in a way that makes sense for standard output. These should be migrated to use the `client.output` methods where possible.
This introduces some additional capabilities on the `MockClient` and `MockStream` classes used in our unit tests.
The bulk of this code is copied over from https://github.com/SBoudrias/Inquirer.js/tree/master/packages/testing, but uses our existing stdin/stdout mocks instead of what's used there.
You can now use `client.getScreen()` to see the "last" screen pushed to stdin, which is super handy for snapshot tests. I've added a few as part of this PR, but many more can be written for our client output as well in the near future.
---
The `client.getScreen()` is also a handy debug tool, use it with `raw: true` to see a pretty printed output during tests:
https://github.com/vercel/vercel/assets/5414297/d0be6078-4901-4eb2-a6c9-1b51b576c1ba
---
This also adds an `events` object on the `MockClient` which allows us to write `client.events.keypress("down")` instead of the less readable `client.stdin.write('\x1B[B')` throughout our testing. This could also be moved to so that it's `client.stdin.keypress(...` or something similar. Note that I've only tested that this works in a login test, included in this PR. If we're happy to make this change I will make update the rest of the unit tests to use this syntax for the inputs.
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@34.0.0
### Major Changes
- Disables promotion of preview deployments
([#11411](https://github.com/vercel/vercel/pull/11411))
### Patch Changes
- Always set `projectSettings.nodeVersion` in `vc deploy`
([#11351](https://github.com/vercel/vercel/pull/11351))
- [cli] optional override of existing environment variables with --force
([#11348](https://github.com/vercel/vercel/pull/11348))
## @vercel/client@13.2.0
### Minor Changes
- Always use v13 of create deployment API endpoint
([#11351](https://github.com/vercel/vercel/pull/11351))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
This is related #11133. This `custom-runtime` tests is failing on that branch since the "macos-14" test runner uses arm64 processor, and the `static-binaries` "import" package that the "vercel-bash" runtime is using does not have binaries for arm64. Switch this test fixture to use "vercel-deno" instead, which won't have this problem.
Add a new vitest-unit test type and specify which npm script to run for a given chunks tests. Currently the CLI unit tests are actually running as part of the Find Changes action, because vitest ignores the `--listTests` flag and just runs the tests immediately.
Updates `@vercel/client` to always use the v13 create-deployment endpoint, even when `builds` is present. This allows for `projectSettings.nodeVersion` to be passed when `builds` is present.
This PR adds changes to the Next.js builder to pass the per-worker environment emitted from the Next.js middleware manifest to the created `EdgeFunction` resource.
Blocks preview deployments from being directly promoted. This relies on a new API version bump.
Copied the warning text from the UI:
This is a breaking change and will require a major version bump. Please don't merge until we're ready.
I did some pruning of old projects on my personal account last night, and accidentally broke CI. I've created a new tarball on the `curated-tests` team so that it doesn't happen again.
The SSO Protection feature is now turned off by default for testing accounts. So this manual logic for disabling the feature on each project test fixture is no longer necessary.
Warn about imminent removal of promoting preview deployments directly to
production.
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
The only changes are from some slightly different punctuation and that typing 'y' or 'n' doesn't process the prompt, it now waits for "Enter". Easiest command to see this is an action is the `init`, if you provided an invalid example to initialize `vercel init astroz` and follow the prompts.
## Fix how we determine the GIT_CONFIG_PATH to support git worktrees and git submodules
We were previously checking for the root of the directory by looking for `.git/config` if the project was not already linked.
This was causing `ENOTDIR` error when checking `.git` in git worktree or git submodule repositories. This is due to `.git` being a file in those repo types with a pointer to the "parent" or "super" repo rather than a directory.
Resolves#10104
`status` here is guaranteed to either be `'linked'` or `'not_linked'` by this point in the code, switching the double negative to a positive condition makes it clearer.
Adds two new helper functions that custom runtimes can utilize in order
to determine whether they should use `provided.al2` or `provided.al2023`
Lambda "runtime" value, based on the build environment.
The new `getProvidedRuntime()` helper function is being used in
`@vercel/go`, so that Go endpoints may be used when the `20.x` Node
Version project setting is used.
Fixes the case in `vc dev` where importing a `.ts` file from another `.ts` file was failing in `vc dev` when `type: "module"` is not set in `package.json`.
Supersedes https://github.com/vercel/vercel/pull/11364.
# Overview
Changing to `@inquirer/prompts` meant updating all existing usage of `inquirer.prompt`. This removed a lot of code since the `inquirer.prompt` function was extra verbose.
The user experience shouldn't have changed much besides different styling. `patch-inquirer` is incompatible with `@inquirer/prompts`. ~~We probably don't want to merge this until we have a new solution for styling.~~ The new default styling is preferred over our old styling.
There are lots of changes over many files, so I went back and organized the commit history. It will probably be easier to review this PR by commit.
## Tests
~~I had to change tests in ways that aren't great. Tests had a hard time recognizing output with escape codes in them, so I had to make the expected output more generic.~~ Using `strip-ansi` worked nicely to ignore styling changes in unit and integration tests.
I removed the unit test "should list projects running on an soon-to-be-deprecated Node.js version" because that test doing `jest.useFakeTimers().setSystemTime(new Date('2023-12-08'));` would make the "should remove a project" test fail. Really strange stuff! Couldn't think of a better solution than removing this, so looking for suggestions here.
Currently the server was binding to the IPV6 [::] catchall on a random
port. The undici request is then unable to reach it.
I only have a mac so I was only able to test this change on Docker for
mac. Would love if someone on windows/linux could validate the change
works for them as well
---------
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
`vc deploy --prebuilt` has not properly worked for projects linked with
`vc link --repo` ever since
https://github.com/vercel/vercel/issues/11077.
To fix, don't mutate `cwd` to be the project subdir (so that `cwd` is
always the monorepo root), and instead pass in a new property to
`@vercel/client` that represents the `.vercel/output` file path. A lot
of the code is just passing this new variable through the multiple
layers of indirection in CLI before it finally reaches `@vercel/client.
Fixes https://github.com/vercel/vercel/issues/11097.
This reverts commit 78e2c012f9.
This commit causes a failing test which contains the `zeroConfig: true`
field. It should have not been merged in the first place due to the
failing test, but Kodiak erroneously merged it before the tests were
passing.
When there are `builds` configuration, the v10 create-deployment
endpoint is used instead of the latest v13 endpoint. `projectSettings`
is not allowed in the v10 endpoint, therefore we can not send the
`nodeVersion` when `builds` project exists. Instead, we should look into
moving away from the v10 endpoint so that we can be using the latest
version of the endpoint for all deployments.
This 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.10.0
### Minor Changes
- Allow environment variables to be specified for `EdgeFunction`
([#11029](https://github.com/vercel/vercel/pull/11029))
## vercel@33.6.2
### Patch Changes
- Added sunset warning to secrets command.
([#11333](https://github.com/vercel/vercel/pull/11333))
- Swap jest for vitest in CLI unit tests
([#11302](https://github.com/vercel/vercel/pull/11302))
- Updated dependencies
\[[`988f7b75a`](988f7b75a2),
[`1825b58df`](1825b58df8)]:
- @vercel/remix-builder@2.1.5
- @vercel/build-utils@7.10.0
- @vercel/node@3.0.25
- @vercel/static-build@2.4.5
## @vercel/client@13.1.8
### Patch Changes
- Updated dependencies
\[[`1825b58df`](1825b58df8)]:
- @vercel/build-utils@7.10.0
## @vercel/frameworks@3.0.1
### Patch Changes
- Swap jest for vitest in CLI unit tests
([#11302](https://github.com/vercel/vercel/pull/11302))
## @vercel/fs-detectors@5.2.2
### Patch Changes
- Updated dependencies
\[[`9ed967034`](9ed967034d)]:
- @vercel/frameworks@3.0.1
## @vercel/gatsby-plugin-vercel-builder@2.0.23
### Patch Changes
- Updated dependencies
\[[`1825b58df`](1825b58df8)]:
- @vercel/build-utils@7.10.0
## @vercel/node@3.0.25
### Patch Changes
- Updated dependencies
\[[`1825b58df`](1825b58df8)]:
- @vercel/build-utils@7.10.0
## @vercel/remix-builder@2.1.5
### Patch Changes
- Add `mjs` and `mts` extensions to vite detection
([#11307](https://github.com/vercel/vercel/pull/11307))
## @vercel/static-build@2.4.5
### Patch Changes
- Updated dependencies \[]:
- @vercel/gatsby-plugin-vercel-builder@2.0.23
## @vercel-internals/types@1.0.28
### Patch Changes
- Updated dependencies
\[[`1825b58df`](1825b58df8)]:
- @vercel/build-utils@7.10.0
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Bumps the core group in /packages/static-build/test/fixtures/astro-v4 with 1 update: [astro](https://github.com/withastro/astro/tree/HEAD/packages/astro).
Updates `astro` from 4.2.0 to 4.5.10
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/withastro/astro/releases">astro's releases</a>.</em></p>
<blockquote>
<h2>astro@4.5.10</h2>
<h3>Patch Changes</h3>
<ul>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10549">#10549</a> <a href="54c2f9707f"><code>54c2f9707f5d038630143f769e3075c698474654</code></a> Thanks <a href="https://github.com/admirsaheta"><code>@admirsaheta</code></a>! - Updates the <code>HTMLAttributes</code> type exported from <code>astro</code> to allow data attributes</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10562">#10562</a> <a href="348c1ca132"><code>348c1ca1323d0516c2dcf8e963343cd12cb5407f</code></a> Thanks <a href="https://github.com/apetta"><code>@apetta</code></a>! - Fixes minor type issues inside the built-in components of Astro</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10550">#10550</a> <a href="34fa8e131b"><code>34fa8e131b85531e6629390307108ffc4adb7ed1</code></a> Thanks <a href="https://github.com/Skn0tt"><code>@Skn0tt</code></a>! - Fixes bug where server builds would include unneeded assets in SSR Function, potentially leading to upload errors on Vercel, Netlify because of size limits</p>
</li>
<li>
<p>Updated dependencies [<a href="c585528f44"><code>c585528f446ccca3d4c643f4af5d550b93c18902</code></a>]:</p>
<ul>
<li><code>@astrojs/markdown-remark</code><a href="https://github.com/4"><code>@4</code></a>.3.2</li>
</ul>
</li>
</ul>
<h2>astro@4.5.9</h2>
<h3>Patch Changes</h3>
<ul>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10532">#10532</a> <a href="8306ce1ff7"><code>8306ce1ff7b71a2a0d7908336c9be462a54d395a</code></a> Thanks <a href="https://github.com/martrapp"><code>@martrapp</code></a>! - Fixes a style issue of <code>client:only</code> components in DEV mode during view transitions.</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10473">#10473</a> <a href="627e47d67a"><code>627e47d67af4846cea2acf26a96b4124001b26fc</code></a> Thanks <a href="https://github.com/bluwy"><code>@bluwy</code></a>! - Fixes and improves performance when rendering Astro JSX</p>
</li>
</ul>
<h2>astro@4.5.8</h2>
<h3>Patch Changes</h3>
<ul>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10504">#10504</a> <a href="8e4e554cc2"><code>8e4e554cc211e59c329c0a5d110c839c886ff120</code></a> Thanks <a href="https://github.com/Princesseuh"><code>@Princesseuh</code></a>! - Update Babel version to fix regression in Babel's <code>7.24.2</code>.</p>
</li>
<li>
<p>Updated dependencies [<a href="19e42c3681"><code>19e42c368184013fc30d1e46753b9e9383bb2bdf</code></a>]:</p>
<ul>
<li><code>@astrojs/markdown-remark</code><a href="https://github.com/4"><code>@4</code></a>.3.1</li>
</ul>
</li>
</ul>
<h2>astro@4.5.7</h2>
<h3>Patch Changes</h3>
<ul>
<li><a href="https://redirect.github.com/withastro/astro/pull/10493">#10493</a> <a href="e4a6462751"><code>e4a6462751725878bfe47632eeafa6854cad5bf2</code></a> Thanks <a href="https://github.com/firefoxic"><code>@firefoxic</code></a>! - <code><link></code> tags created by astro for optimized stylesheets now do not include the closing forward slash. This slash is optional for void elements such as link, but made some html validation fail.</li>
</ul>
<h2>astro@4.5.6</h2>
<h3>Patch Changes</h3>
<ul>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10455">#10455</a> <a href="c12666166d"><code>c12666166db724915e42e37a048483c99f88e6d9</code></a> Thanks <a href="https://github.com/lilnasy"><code>@lilnasy</code></a>! - Adds a helpful error message that will be shown when an endpoint does not return a <code>Response</code>.</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10426">#10426</a> <a href="6a9a35ee15"><code>6a9a35ee15069541c3144012385366a3c689240a</code></a> Thanks <a href="https://github.com/markgaze"><code>@markgaze</code></a>! - Fixes an issue with generating JSON schemas when the schema is a function</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10448">#10448</a> <a href="fcece36586"><code>fcece3658697248ab58f77b3d4a8b14d362f3c47</code></a> Thanks <a href="https://github.com/lilnasy"><code>@lilnasy</code></a>! - Fixes an issue where multiple rendering errors resulted in a crash of the SSR app server.</p>
</li>
</ul>
<h2>astro@4.5.5</h2>
<h3>Patch Changes</h3>
<ul>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10379">#10379</a> <a href="3776ecf0aa"><code>3776ecf0aa9e08a992d3ae76e90682fd04093721</code></a> Thanks <a href="https://github.com/1574242600"><code>@1574242600</code></a>! - Fixes a routing issue with partially truncated dynamic segments.</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10442">#10442</a> <a href="f8e0ad3c52"><code>f8e0ad3c52a37b8a2175fe2f5ff2bd0cd738f499</code></a> Thanks <a href="https://github.com/Princesseuh"><code>@Princesseuh</code></a>! - Fixes small rendering issues with the dev toolbar in certain contexts</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10438">#10438</a> <a href="5b48cc0fc8"><code>5b48cc0fc8383b0659a595afd3a6ee28b28779c3</code></a> Thanks <a href="https://github.com/bholmesdev"><code>@bholmesdev</code></a>! - Generate Astro DB types when running <code>astro sync</code>.</p>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/withastro/astro/blob/main/packages/astro/CHANGELOG.md">astro's changelog</a>.</em></p>
<blockquote>
<h2>4.5.10</h2>
<h3>Patch Changes</h3>
<ul>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10549">#10549</a> <a href="54c2f9707f"><code>54c2f9707f5d038630143f769e3075c698474654</code></a> Thanks <a href="https://github.com/admirsaheta"><code>@admirsaheta</code></a>! - Updates the <code>HTMLAttributes</code> type exported from <code>astro</code> to allow data attributes</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10562">#10562</a> <a href="348c1ca132"><code>348c1ca1323d0516c2dcf8e963343cd12cb5407f</code></a> Thanks <a href="https://github.com/apetta"><code>@apetta</code></a>! - Fixes minor type issues inside the built-in components of Astro</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10550">#10550</a> <a href="34fa8e131b"><code>34fa8e131b85531e6629390307108ffc4adb7ed1</code></a> Thanks <a href="https://github.com/Skn0tt"><code>@Skn0tt</code></a>! - Fixes bug where server builds would include unneeded assets in SSR Function, potentially leading to upload errors on Vercel, Netlify because of size limits</p>
</li>
<li>
<p>Updated dependencies [<a href="c585528f44"><code>c585528f446ccca3d4c643f4af5d550b93c18902</code></a>]:</p>
<ul>
<li><code>@astrojs/markdown-remark</code><a href="https://github.com/4"><code>@4</code></a>.3.2</li>
</ul>
</li>
</ul>
<h2>4.5.9</h2>
<h3>Patch Changes</h3>
<ul>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10532">#10532</a> <a href="8306ce1ff7"><code>8306ce1ff7b71a2a0d7908336c9be462a54d395a</code></a> Thanks <a href="https://github.com/martrapp"><code>@martrapp</code></a>! - Fixes a style issue of <code>client:only</code> components in DEV mode during view transitions.</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10473">#10473</a> <a href="627e47d67a"><code>627e47d67af4846cea2acf26a96b4124001b26fc</code></a> Thanks <a href="https://github.com/bluwy"><code>@bluwy</code></a>! - Fixes and improves performance when rendering Astro JSX</p>
</li>
</ul>
<h2>4.5.8</h2>
<h3>Patch Changes</h3>
<ul>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10504">#10504</a> <a href="8e4e554cc2"><code>8e4e554cc211e59c329c0a5d110c839c886ff120</code></a> Thanks <a href="https://github.com/Princesseuh"><code>@Princesseuh</code></a>! - Update Babel version to fix regression in Babel's <code>7.24.2</code>.</p>
</li>
<li>
<p>Updated dependencies [<a href="19e42c3681"><code>19e42c368184013fc30d1e46753b9e9383bb2bdf</code></a>]:</p>
<ul>
<li><code>@astrojs/markdown-remark</code><a href="https://github.com/4"><code>@4</code></a>.3.1</li>
</ul>
</li>
</ul>
<h2>4.5.7</h2>
<h3>Patch Changes</h3>
<ul>
<li><a href="https://redirect.github.com/withastro/astro/pull/10493">#10493</a> <a href="e4a6462751"><code>e4a6462751725878bfe47632eeafa6854cad5bf2</code></a> Thanks <a href="https://github.com/firefoxic"><code>@firefoxic</code></a>! - <code><link></code> tags created by astro for optimized stylesheets now do not include the closing forward slash. This slash is optional for void elements such as link, but made some html validation fail.</li>
</ul>
<h2>4.5.6</h2>
<h3>Patch Changes</h3>
<ul>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10455">#10455</a> <a href="c12666166d"><code>c12666166db724915e42e37a048483c99f88e6d9</code></a> Thanks <a href="https://github.com/lilnasy"><code>@lilnasy</code></a>! - Adds a helpful error message that will be shown when an endpoint does not return a <code>Response</code>.</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10426">#10426</a> <a href="6a9a35ee15"><code>6a9a35ee15069541c3144012385366a3c689240a</code></a> Thanks <a href="https://github.com/markgaze"><code>@markgaze</code></a>! - Fixes an issue with generating JSON schemas when the schema is a function</p>
</li>
<li>
<p><a href="https://redirect.github.com/withastro/astro/pull/10448">#10448</a> <a href="fcece36586"><code>fcece3658697248ab58f77b3d4a8b14d362f3c47</code></a> Thanks <a href="https://github.com/lilnasy"><code>@lilnasy</code></a>! - Fixes an issue where multiple rendering errors resulted in a crash of the SSR app server.</p>
</li>
</ul>
<h2>4.5.5</h2>
<h3>Patch Changes</h3>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="bb7707e171"><code>bb7707e</code></a> [ci] release (<a href="https://github.com/withastro/astro/tree/HEAD/packages/astro/issues/10556">#10556</a>)</li>
<li><a href="348c1ca132"><code>348c1ca</code></a> Patch for Astro VS Code Plugin type errors (<a href="https://github.com/withastro/astro/tree/HEAD/packages/astro/issues/10562">#10562</a>)</li>
<li><a href="51a4ea5f72"><code>51a4ea5</code></a> fix(types): Fixes HTMLAttribute extend to allow everything (<a href="https://github.com/withastro/astro/tree/HEAD/packages/astro/issues/10561">#10561</a>)</li>
<li><a href="34fa8e131b"><code>34fa8e1</code></a> fix: ensure outDir doesn't lead to bundlers bloating Lambda size (<a href="https://github.com/withastro/astro/tree/HEAD/packages/astro/issues/10550">#10550</a>)</li>
<li><a href="54c2f9707f"><code>54c2f97</code></a> Fix: Type error on <code>\<Image /></code> component when strict TypeScript rules are use...</li>
<li><a href="1cd2a74022"><code>1cd2a74</code></a> [ci] release (<a href="https://github.com/withastro/astro/tree/HEAD/packages/astro/issues/10522">#10522</a>)</li>
<li><a href="8306ce1ff7"><code>8306ce1</code></a> Fixes a style issue of <code>client:only</code> components in DEV mode during view trans...</li>
<li><a href="8cac744746"><code>8cac744</code></a> Avoid generators in render head API (<a href="https://github.com/withastro/astro/tree/HEAD/packages/astro/issues/10528">#10528</a>)</li>
<li><a href="ca5455af3d"><code>ca5455a</code></a> Avoid generators when crawling module graph (<a href="https://github.com/withastro/astro/tree/HEAD/packages/astro/issues/10529">#10529</a>)</li>
<li><a href="627e47d67a"><code>627e47d</code></a> Improve Astro JSX rendering (<a href="https://github.com/withastro/astro/tree/HEAD/packages/astro/issues/10473">#10473</a>)</li>
<li>Additional commits viewable in <a href="https://github.com/withastro/astro/commits/astro@4.5.10/packages/astro">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions
</details>
* Forces the AL2 build container image for fixtures that depend on it,
via `engines.node` in package.json for most cases.
* The `testDeployment()` function was updated to send
`projectSettings.nodeVersion` in the POST body, to mimic the behavior in
CLI.
* For Go, Ruby, and Python tests, the `projectSettings.nodeVersion`
property is set "globally" in the Jest setup file, so that individual
fixtures didn't need to be adjusted.
We have to enforce the node version on some examples to make sure they
are not auto upgraded in the future before we support their runtime.
See https://vercel.com/docs/deployments/build-image
My project was being incorrectly detected as not vite, thus it was failing in runtime. My vite config is `vite.config.mts` so this PR fixes detection logic to include `mjs` and `mts` extensions.
The fix can be generalized if needed.
This unit test fails on my machine:
```
Expected: "pnpm i vercel@latest"
Received: "pnpm i -g vercel@latest"
```
This change allows the test to succeed on machines that need the `-g` flag.
In legacy Remix apps, we were running `npm install` once again before globbing the `node_modules` dir due to the injecting of the forked Remix compiler which would cause a cache miss without that happening.
For Vite, we are no longer mucking about `node_modules` at build-time, so there is no need to run `npm install` in the `prepareCache()` function.
There is also no "cacheDirectory" setting so the globbing of the legacy cache directory is also moved into the legacy-only logic.
**tl;dr** For Remix + Vite apps, the only thing that needs to be cached is `node_modules`.
Previously, we used `semver` which correctly identified the nodeVersion used in `package.json`, but failed in two cases:
1. If the specified `engines` range started too low, it wouldn't correctly identify a later version compatible with Vercel. (`">10"` was detecting as Node `"10.x"` not `"20.x"`)
2. If the specified `engines` version was fixed too low to be compatible with Vercel, we sent it, and then Vercel predictably errored. (`"10"` was detecting as Node `"10.x"` which would lead to an error in the build process)
Now, case 1 should properly use the latest node version. And case 2 will not send a node version override to the API and will print a warning to the user on the CLI, but the deployment will still proceed with the version specified for the project in the web interface.
We chose to keep the error message shown to the user consistent with what shows in the logs for the build container, that is:
> WARN! Node.js Version "10.x" is discontinued and must be upgraded. Please set "engines": { "node": "20.x" } in your `package.json` file to use Node.js 20.
When there's a match for a prerender, the dynamic query parameters will
not be provided via the `x-now-route-matches`. This ensures that when
generating any static route that the static streaming lambda path is
used if it's provided, ensuring that when a page is generated via
`generateStaticParams`:
```tsx
// app/blog/[slug]/page.tsx
type Props = {
params: {
slug: string
}
}
export function generateStaticParams() {
return [{ slug: "one" }, { slug: "two" }, { slug: "three" }]
}
export default function BlogPage({ slug }: Props) {
// ...
}
```
That we use the specific routes (`/blog/one`, `/blog/two`, and
`/blog/three`) for the partial prerendering streaming path instead of
the paramatarized pathname (`/blog/[slug]`) as the rewrites won't be
matched once a match for a prerender has been found.
This additionally updates the tests to ensure that the correct pathname
is observed (this was previously silently failing).
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.9.0
### Minor Changes
- Add `base` parameter to `scanParentDirs()`
([#11261](https://github.com/vercel/vercel/pull/11261))
## vercel@33.6.0
### Minor Changes
- Set `projectSettings.nodeVersion` in `vc deploy` based on
"engines.node" field
([#11261](https://github.com/vercel/vercel/pull/11261))
### Patch Changes
- Stops warning about legacy Speed Insights for Next.js apps
([#11268](https://github.com/vercel/vercel/pull/11268))
- Fix framework version detection in monorepos
([#11212](https://github.com/vercel/vercel/pull/11212))
- Updated dependencies
\[[`8ea93839c`](8ea93839cc),
[`58ef91bfe`](58ef91bfe8)]:
- @vercel/build-utils@7.9.0
- @vercel/remix-builder@2.1.3
- @vercel/node@3.0.23
- @vercel/static-build@2.4.3
## @vercel/client@13.1.6
### Patch Changes
- Updated dependencies
\[[`8ea93839c`](8ea93839cc)]:
- @vercel/build-utils@7.9.0
## @vercel/gatsby-plugin-vercel-builder@2.0.21
### Patch Changes
- Updated dependencies
\[[`8ea93839c`](8ea93839cc)]:
- @vercel/build-utils@7.9.0
## @vercel/node@3.0.23
### Patch Changes
- Updated dependencies
\[[`8ea93839c`](8ea93839cc)]:
- @vercel/build-utils@7.9.0
## @vercel/remix-builder@2.1.3
### Patch Changes
- Improve hueristics for detecting Remix + Vite
([#11256](https://github.com/vercel/vercel/pull/11256))
## @vercel/static-build@2.4.3
### Patch Changes
- Updated dependencies \[]:
- @vercel/gatsby-plugin-vercel-builder@2.0.21
## @vercel-internals/types@1.0.26
### Patch Changes
- Updated dependencies
\[[`8ea93839c`](8ea93839cc)]:
- @vercel/build-utils@7.9.0
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
### 🧐 What's in there?
Vercel's Speed Insights legacy injection is deprecated in favor of `@vercel/speed-insights` package.
CLI has a couple places where it warns users running `vc build` locally (or on their CI).
Some users complained about seeing the warning while they are already using the package.
This PR removes the message
### ❗ Note to reviewers
@tobiaslins, @timolins and I had a long discussion on the approach here.
This warning is issued because during `vc pull`, the project API on Vercel returns a legacy analytics.id field, [which is stored](https://github.com/vercel/vercel/blame/main/packages/cli/src/util/projects/project-settings.ts#L35) in `.vercel/project.json`.
While it is legit for users who never used `@vercel/speed-insights` package, it also appear for users who migrated from legacy.
Besides setting the warning, `VERCEL_ANALYTICS_ID` is set, which triggers auto-injection in Next.js, and is useful during self-hosting.
We first considered removing the legacy id from `project.json`, but it would break self-hosting.
We also considered printing the warning only if the application never used the package (which the project API on Vercel knows).
In the end, we realized that vercel.com Speed Insights dashboard has plenty of disclaimer and incentives to use the new package. Having it in the CLI doesn't worth the annoyance.
I tagged everyone for review that might be impacted. I removed no one, but added Zero Config to each section.
This allows Zero Config to make uncontroversial tweaks as needed. For any significant changes to these areas, we'd of course still wait for other teams' reviews.
Read the package.json and use the `engines.node` value to set the
`projectSettings.nodeVersion` property on the create deployment API call
POST body. This allows for the Node 20 build container image to be
properly specified before the deployment is created on the server side.
I noticed that the framework version was not being printed on deployments in a monorepo. Turns out the framework detection logic was happening at the root of the monorepo, instead of the project directory.
In particular, when both `remix.config` and `vite.config` files exist,
run some additional checks to try to detect if the project is using the
Vite plugin or not.
There's an issue with `vc link` and `vc deploy` when using a project
root directory. Framework detection fails because it's looking in the
wrong directory.
---
Manually tested and this fixes the issue. A project with a rootDirectory
was previously not detecting a framework, but now it says:
```
Auto-detected Project Settings (Remix):
```
---------
Co-authored-by: Nathan Rajlich <n@n8.io>
- Removes all the legacy `flags`
- Renames the new `variants` to `flags`
Neither the legacy flags, nor the new variants were exposed to anyone, except for the type in build-utils, so there shouldn't be any issues removing/renaming them.
Remove these old tests for the legacy BOA version. Specifically,
`66-build-output-directory-with-functions` has become problematic
because the "go1.x" Lambda runtime no longer deploys. I figured we take
the opportunity to remove the others as well though. Will make running
the tests slightly faster.
This function can lead to unexpected results (for example, in a monorepo setup where there were different versions of Remix being used, I encountered the wrong version of Remix being symlinked causing issues at runtime).
Instead, throw an error at build time at the NFT step if `@remix-run/node` is missing for routes using Node.js, or when `@remix-run/server-runtime` is missing for routes using Edge.
Less magical is better. Explicit is better than implicit.
This reverts commit 1a45731c92. This
should not have been merged yet. There is still an issue with framework
detection selecting Vite instead of Remix preset.
Customer reported an edge case where (in a monorepo) their project's
`package.json` did not list any dependencies (instead they are listed at
the root-level `package.json`) and this caused the `node_modules`
directory to not exist in the app subdirectory, causing
`ensureSymlink()` to fail.
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/frameworks@3.0.0
### Major Changes
- Make "remix" framework preset supersede "vite"
([#11031](https://github.com/vercel/vercel/pull/11031))
## @vercel/fs-detectors@5.2.0
### Minor Changes
- Make "remix" framework preset supersede "vite"
([#11031](https://github.com/vercel/vercel/pull/11031))
### Patch Changes
- Updated dependencies
\[[`1333071a3`](1333071a3a)]:
- @vercel/frameworks@3.0.0
## @vercel/remix-builder@2.1.0
### Minor Changes
- Remix Vite plugin support
([#11031](https://github.com/vercel/vercel/pull/11031))
## vercel@33.5.3
### Patch Changes
- Updated dependencies
\[[`c2d99855e`](c2d99855ea),
[`1333071a3`](1333071a3a)]:
- @vercel/next@4.1.3
- @vercel/remix-builder@2.1.0
## @vercel/next@4.1.3
### Patch Changes
- Fix manifest with experimental flag
([#11192](https://github.com/vercel/vercel/pull/11192))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Adds support for Remix apps which use the new Remix Vite plugin.
* The vanilla Remix + Vite template deploys correctly out-of-the-box,
however only a single Node.js function will be used, and a warning will
be printed saying to configure the `vercelPreset()` Preset.
* When used in conjunction with the `vercelPreset()` Preset
(https://github.com/vercel/remix/pull/81), allows for the application to
utilize Vercel-specific features, like per-route `export const config`
configuration, including multi-runtime (Node.js / Edge runtimes) within
the same app.
## To test this today
1. Generate a Remix + Vite project from the template:
```
npx create-remix@latest --template remix-run/remix/templates/vite
```
1. Install `@vercel/remix`:
```
npm i --save-dev @vercel/remix
```
1. **(Before Remix v2.8.0 is released)** - Update the `@remix-run/dev`
dependency to use the "pre" tag which contains [a bug
fix](https://github.com/remix-run/remix/pull/8864):
```
npm i --save--dev @remix-run/dev@pre @remix-run/serve@pre
```
1. Configure the `vercelPreset()` in the `vite.config.ts` file:
```diff
--- a/vite.config.ts
+++ b/vite.config.ts
@@ -1,10 +1,11 @@
import { vitePlugin as remix } from "@remix-run/dev";
import { installGlobals } from "@remix-run/node";
import { defineConfig } from "vite";
+import { vercelPreset } from "@vercel/remix/vite";
import tsconfigPaths from "vite-tsconfig-paths";
installGlobals();
export default defineConfig({
- plugins: [remix(), tsconfigPaths()],
+ plugins: [remix({ presets: [vercelPreset()] }), tsconfigPaths()],
});
```
1. Create a new Vercel Project in the dashboard, and ensure the Vercel
preset is set to "Remix" in the Project Settings. The autodetection will
work correctly once this PR is merged, but for now it gets incorrectly
detected as "Vite" preset.
* **Hint**: You can create a new empty Project by running the `vercel
link` command.
<img width="545" alt="Screenshot 2024-02-27 at 10 37 11"
src="https://github.com/vercel/vercel/assets/71256/f46baf57-5d97-4bde-9529-c9165632cb30">
1. Deploy to Vercel, setting the `VERCEL_CLI_VERSION` environment
variable to use the changes in this PR:
```
vercel deploy -b
VERCEL_CLI_VERSION=https://vercel-git-tootallnate-zero-1217-research-remix-v-next-vite.vercel.sh/tarballs/vercel.tgz
```
This ensures we don't attempt the manifests filtering behavior with this
experimental flag enabled as it is incompatible with it as we don't know
what to filter by at this point.
This doesn't change any functionality, and only replaces some mutable types (like `Map`, `Set`, and `Array`) with their immutable versions (like `ReadonlyMap`, `ReadonlySet`, and `ReadonlyArray`). This can help keep functions as pure as possible and improves the readability of some of the involved functions.
Adds a check to ensure the `serverBuildPath` for the server bundles was created. If it was not, then that means the Vercel forked Remix compiler was not used, and we must fall back to a singular server bundle.
The fork of the Remix compiler is only necessary when the project is utilizing split configurations in their routes (i.e. mixing Node.js and Edge functions).
However, the injecting of the forked compiler has proven to be brittle and has many edge cases which cause the fork to not be present. Considering that the more common case is to _not_ use split configuration, skip the fork entirely when that is the case.
This is somewhat of a band-aid / hold over for the "old" Remix. With the Remix + Vite configuration, the fork will be entirely unnecessary.
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.7.0
### Minor Changes
- Revert "Revert "Default ruby to only currently supported version
(3.2.0)"" ([#11137](https://github.com/vercel/vercel/pull/11137))
## @vercel/static-build@2.4.0
### Minor Changes
- Revert "Revert "Default ruby to only currently supported version
(3.2.0)"" ([#11137](https://github.com/vercel/vercel/pull/11137))
### Patch Changes
- Updated dependencies \[]:
- @vercel/gatsby-plugin-vercel-builder@2.0.18
## vercel@33.5.1
### Patch Changes
- build: upgrade edge-runtime
([#11148](https://github.com/vercel/vercel/pull/11148))
- Updated dependencies
\[[`24c3dd282`](24c3dd282d),
[`10e200e0b`](10e200e0bf),
[`678ebbe52`](678ebbe525)]:
- @vercel/build-utils@7.7.0
- @vercel/static-build@2.4.0
- @vercel/node@3.0.19
## @vercel/client@13.1.3
### Patch Changes
- Updated dependencies
\[[`24c3dd282`](24c3dd282d)]:
- @vercel/build-utils@7.7.0
## @vercel/gatsby-plugin-vercel-builder@2.0.18
### Patch Changes
- Updated dependencies
\[[`24c3dd282`](24c3dd282d)]:
- @vercel/build-utils@7.7.0
## @vercel/node@3.0.19
### Patch Changes
- build: upgrade edge-runtime
([#11148](https://github.com/vercel/vercel/pull/11148))
- refactor: simplify content-length check
([#11150](https://github.com/vercel/vercel/pull/11150))
- Updated dependencies
\[[`24c3dd282`](24c3dd282d)]:
- @vercel/build-utils@7.7.0
## @vercel-internals/types@1.0.23
### Patch Changes
- Updated dependencies
\[[`24c3dd282`](24c3dd282d)]:
- @vercel/build-utils@7.7.0
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
The Next.js change in https://github.com/vercel/next.js/pull/61794 means
that the `Vary` header will contain `Next-Url` less often. We need to
update the assertions on our end to accommodate.
This reverts commit de63e35622 / #11104.
We had no great way to test this without release but we have other
things we'd like to deploy today. Will revert the revert when we're
closer to fixing just this issue.
This PR changes the default package manager from `yarn` to `npm` in the case that no lockfile is present.
Many years ago when `yarn` was first released, it was much faster than `npm` so we used it by default. That is no longer the case today and `yarn@1` is no longer receiving new features.
For example, `sharp` and `esbuild` no longer works with `yarn@1`:
### Related
- https://github.com/lovell/sharp/issues/3750
- https://github.com/evanw/esbuild/issues/2949
Note that this change will not impact most projects because most used a lockfile.
This PR adds requiring the modules that _we know_ will be required in
the Next.js Lambda in the module scope in a attempt to make a better use
of resources.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Makes adjustments to replace `flags` with `variants`.
Also marks the current `flags` implementation as deprecated, as it
should get removed soon. Which I'll do in a follow up PR.
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/static-build@2.2.0
### Minor Changes
- Default ruby to only currently supported version (3.2.0)
([#11104](https://github.com/vercel/vercel/pull/11104))
### Patch Changes
- [tests] Update Gatsby fixture versions
([#11101](https://github.com/vercel/vercel/pull/11101))
## vercel@33.4.1
### Patch Changes
- Updated dependencies
\[[`d05e41eea`](d05e41eeaf),
[`de63e3562`](de63e35622)]:
- @vercel/static-build@2.2.0
## @vercel/client@13.1.1
### Patch Changes
- More helpful error message when `vc deploy --prebuilt` has missing
files ([#11105](https://github.com/vercel/vercel/pull/11105))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
We're currently using the directory name at `./vendor/bundle/ruby/`[0]
to determine ruby version. This directory is created as part of running
`bundle install` during the build process. However, when multiple ruby
versions are available, you can end up with multiple directories and the
0th entry at `./vendor/bundle/ruby/` isn't guaranteed to be the Ruby
version specified in the project.
Other companies in this space seem to do some order of
- check for value in `.ruby-version` file
- check for value passed into `ruby` directive in the Gemfile
- check the value in the `*.gemspec` file if the Gemfile has a `gemspec`
directive.
We'll do that work in a future PR but for _now_ our only supported Ruby
version is Ruby 3.2.x [as of
2023-11-22](https://vercel.com/changelog/upgrading-ruby-v2-7-to-v3-2).
So this can be hard-coded for the moment.
Skipping ruby tests now since these target _current_ prod where Ruby
3.2.x is not in `PATH` until we redeploy after this gets deployed.
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.4.0
### Minor Changes
- Added a new option to add a sensitive environment variable
([#11033](https://github.com/vercel/vercel/pull/11033))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
This is a performance / bandwidth / storage space optimization for the **Build Output API**.
When a Builder returns function which contains a file that is a `FileFsRef` instance, it _won't_ be copied into the corresponding `.func` directory, but instead will be added to a `"files"` mapping in the `.vc-config.json` file. This mapping represents keys which are destination file paths within the function filesystem, and values which are relative paths from the root of the project codebase. This allows for common files (i.e. `node_modules`) to be referenced (instead of physically copied on the disk).
This introduces an additional complexity to `vc deploy --prebuilt`, in such that now it needs to build up the list of `"files"` referenced from the `.vc-config.json` files, and _also_ upload those file paths along with the `.vercel/output` directory.
Depends on:
* https://github.com/vercel/vercel/pull/11077
* https://github.com/vercel/vercel/pull/11080
* Use `Lambda` constructor instead of `createLambda()`
* Return `FileBlob` instance for the entrypoint files, so that they do not get written to cwd
* In `vc dev`, support `Lambda` instances which do not have `zipBuffer` property
Ensure that files referenced by the `filePathMap` property in the `.vc-config.json` files for functions in the Build Output API `.vercel/output` directory are uploaded during the prebuilt deployment process.
Related to / precursor for https://github.com/vercel/vercel/pull/11060.
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.2.0
### Minor Changes
- chore: deprecate next/nuxt/gastby Speed Insights injection in favor of @vercel/speed-insights ([#11048](https://github.com/vercel/vercel/pull/11048))
### Patch Changes
- fix error when @vercel/analytics is a transitive dependency of the deployed application ([#10892](https://github.com/vercel/vercel/pull/10892))
- [cli] Add documentation string for `skip-domain` option ([#11051](https://github.com/vercel/vercel/pull/11051))
- Updated dependencies \[[`260125784`](2601257846), [`cdddb33ad`](cdddb33ad4), [`72d8604c9`](72d8604c9d), [`90d0455e1`](90d0455e1f), [`0716130e5`](0716130e58), [`b6b151f39`](b6b151f391), [`b185a7e20`](b185a7e207)]:
- @vercel/static-build@2.1.0
- @vercel/build-utils@7.5.1
- @vercel/next@4.1.0
- @vercel/remix-builder@2.0.18
- @vercel/node@3.0.17
## @vercel/next@4.1.0
### Minor Changes
- fix error when @vercel/analytics is a transitive dependency of the deployed application ([#10892](https://github.com/vercel/vercel/pull/10892))
### Patch Changes
- Use `worker.name` instead of edge function name to fix type error in `@vercel/next` ([#11050](https://github.com/vercel/vercel/pull/11050))
## @vercel/static-build@2.1.0
### Minor Changes
- chore: deprecate next/nuxt/gastby Speed Insights injection in favor of @vercel/speed-insights ([#11048](https://github.com/vercel/vercel/pull/11048))
### Patch Changes
- Updated dependencies \[]:
- @vercel/gatsby-plugin-vercel-builder@2.0.16
## @vercel/build-utils@7.5.1
### Patch Changes
- Add experimental field to Lambda and size to FileFsRef output ([#11059](https://github.com/vercel/vercel/pull/11059))
## @vercel/client@13.0.14
### Patch Changes
- Updated dependencies \[[`cdddb33ad`](cdddb33ad4)]:
- @vercel/build-utils@7.5.1
## @vercel/gatsby-plugin-vercel-builder@2.0.16
### Patch Changes
- Updated dependencies \[[`cdddb33ad`](cdddb33ad4)]:
- @vercel/build-utils@7.5.1
## @vercel/node@3.0.17
### Patch Changes
- Updated dependencies \[[`cdddb33ad`](cdddb33ad4)]:
- @vercel/build-utils@7.5.1
## @vercel/remix-builder@2.0.18
### Patch Changes
- Fix functions without a output path edge case ([#11038](https://github.com/vercel/vercel/pull/11038))
- Update `@remix-run/dev` fork to v2.5.0 ([#11054](https://github.com/vercel/vercel/pull/11054))
- Update `@remix-run/dev` fork to v2.5.1 ([#11065](https://github.com/vercel/vercel/pull/11065))
## @vercel-internals/types@1.0.21
### Patch Changes
- Updated dependencies \[[`cdddb33ad`](cdddb33ad4)]:
- @vercel/build-utils@7.5.1
### 🧐 What's in there?
With the recent release of [`@vercel/speed-insights`](https://vercel.com/docs/speed-insights/package) own package (like [`@vercel/analytics`](https://vercel.com/docs/analytics/package)), it's time to encourage users to migrate.
With the availability of `@vercel/speed-insights`, users will have to opt-in explicitly by installing the package. Their benefit is a better and fine-grained control of the reporting (in particular, per-application sample rate).
### ❗ Note to reviewers
I used `console.warn` and hope it will stands out in the build logs. I'm happy to use anything else if you have better suggestions.
There's also a deprecation warning in Next.js, which covers a related but slightly different case, when users explicitly pass analyticsId in their configuration. https://github.com/vercel/next.js/pull/60677
This adds a new experimental field for new bundling behavior. This also
adds an optional `size` field to the FileFsRef output since we already
stat to avoid having to re-stat to get this value.
Fixes an edge case where a route without a path was causing the build to
fail. Reproducible with this `remix.config.js` file:
```js
export default {
ignoredRouteFiles: ["**/.*"],
routes(defineRoutes) {
return defineRoutes((route) => {
route("/", "foo.tsx", { index: true });
});
},
};
```
Enables the symlink optimization that currently exists for `Lambda`
instances, but now for `EdgeFunction` instances as well. This will be
particularly beneficial for Remix applications which use edge functions
for many routes, since they will now all be represented by the same
underling function in production.
---------
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
The `name` property of the `EdgeFunction` class is no longer necessary
on the infra side. Instead, its value is inferred based on the URL path
that the function is representing. So deprecate the property on the
class, and remove its usage throughout the codebase.
The CLI renders the deploy URL with the "Preview" label on first deploy because the CLI treats deploys as previews unless `--prod` is set. However the first deploy for a new project is always production, so the CLI needs to render the deploy URL based on the actual deployment's `target`.
This ensures we add handling for our internal `.rsc` suffixes for rewrites since this currently fail to match by default unless the user manually adds handling for this. Updated our test fixture to ensure this is tested properly.
The ionic react build currently fails with:
```
$ react-scripts build
09:06:23.084 | Creating an optimized production build...
09:06:45.231 | Failed to compile.
09:06:45.231 |
09:06:45.232 | /vercel/path0/node_modules/@types/babel__traverse/index.d.ts
09:06:45.232 | TypeScript error in /vercel/path0/node_modules/@types/babel__traverse/index.d.ts(314,13):
09:06:45.232 | Type expected. TS1110
09:06:45.232 |
09:06:45.232 | 312 \| // too complex for TS. So we type it as a general visitor only if the key contains `\|`
09:06:45.232 | 313 \| // this is good enough for non-visitor traverse options e.g. `noScope`
09:06:45.232 | > 314 \| [k: `${string}\|${string}`]: VisitNode<S, Node>;
09:06:45.232 | \| ^
09:06:45.232 | 315 \| };
09:06:45.232 | 316 \|
09:06:45.232 | 317 \| export type VisitNode<S, P extends Node> = VisitNodeFunction<S, P> \| VisitNodeObject<S, P>;
09:06:45.232
```
Upgrading to TypeScript 4 fixes the issue.
---------
Co-authored-by: Trek Glowacki <trek.glowacki@vercel.com>
update ionic/angular to latest v7. Needed to add and `overrides` entry.
Some packages just specify angular >= 14 and this bumps us to angular
17, which we're not ready for yet.
Undoes #10980 (mostly). This appears to be some kind of caching issue. Works locally until you run `eslint` without `--cache` and then it will reproduce. Hopefully this is the last time and we're not playing whack-a-mole with these pragmas every day?
Say you have a middleware (`middleware.js`) that looks like this:
```js
export async default function middleware(req, ctx) {
ctx.waitUntil(tooLongFunction())
}
async function tooLongFunction() {
console.log('tooLongFunction started')
await new Promise((resolve) => setTimeout(resolve, 10000))
console.log('tooLongFunction finished')
}
```
When you run this middleware locally with `vercel dev`, you won't see the `tooLongFunction finished` message because the server process is killed right after finishing the response. While Edge Runtime's `server.close()`, which awaits all `waitUntil` promises, is called, but `exit-hook`'s callback in CLI doesn't wait for the `close` promise to resolve.
This PR fixes this by allowing an optional graceful shutdown callback instead of killing the process immediately.
Previously routes that did not have a `dataRoute` key in the `prerender-manifest.json` would be treated as an App Route. The logic has been updated (for partial prerendering support) to also consider the new `prefetchDataRoute`. Entries with either of these keys are treated as an App Page instead of an App Route.
This also addressed the scenerio where a app route (`route.ts`) with a dynamic segment (`/api/[slug]/route.ts`) which doesn't emit a `.body` during build doesn't cause the build to fail by checking for the file first.
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))
During `vc build` do following when `@vercel/speed-insights` package is in dependencies:
- Show a warning when `VERCEL_ANALYTICS_ID` is set in environment variables
- Unset it in process.env to prevent auto-injecting old speed insights in Next.js
Durning `vc env pull` prevent pulling internal environment variables `VERCEL_ANALYTICS_ID`, `VERCEL_SPEED_INSIGHTS_ID` & `VERCEL_WEB_ANALYTICS_ID`. They are never required in the frontend
Removes the two-staged `tsc` build into a single `esbuild` bundle. The `ssr-handler.ts` template file is moved to the root of the package and converted to JavaScript.
The "babel" build for this package essentially does nothing. The output is still using ESM and no transformation is done. Let's just remove the "build" script entirely.
To be consistent with the other packages that use `@vercel/static-config`/`ts-morph`, move these packages to "dependencies" so that they will be excluded from the bundle, and de-duped at the `node_modules` level when installing CLI.
Updating `nft` to fix a bug. We're a couple version behind. Here's all cumulative changes:
- 0.24.1
- resolve cjs deps as cjs instead of esm
- 0.24.0
- drop node@14
- 0.23.1
- use builtinModules from module
- 0.23.0
- resolve: export resolve() function
- 0.22.6
- Make caching work correctly in async context
Similar to the default import fix from #10525 which was for Node runtime, but this one fixes Edge runtime.
Also adds an E2E test for Remix v2, including both a Node route and Edge route.
Restores DataDog flakey test detection. Briefly disabled because the old method of using exit codes would bail the entire workflow.
Taking the Turbo team's suggestion of looking at `runData.execution` values to avoid an extra loop. Now with unit tests!
For feature flags, we use the string `1` for enabled and the string `0` for disabled.
So we need to check the value of the env var, not the presence of the env var.
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/fs-detectors@5.1.0
### Minor Changes
- Add support for bun detection in monorepo
([#10511](https://github.com/vercel/vercel/pull/10511))
## vercel@32.2.4
### Patch Changes
- Add support for bun detection in monorepo
([#10511](https://github.com/vercel/vercel/pull/10511))
- Updated dependencies
\[[`1b6f3a0f6`](1b6f3a0f65)]:
- @vercel/static-build@2.0.6
## @vercel/static-build@2.0.6
### Patch Changes
- Add support for bun detection in monorepo
([#10511](https://github.com/vercel/vercel/pull/10511))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
From the [sounds of
it](https://github.com/changesets/changesets/blob/main/docs/experimental-options.md#updateinternaldependents-type-out-of-range--always),
setting this config value to "always" will make it so that a patch
release will happen for a package that depends on another package which
is being bumped. This would normally happen anyways, but does not happen
when a dependency is a `devDependency` rather than a `dependency` (which
happens for the Builders and CLI, since those packages get bundled and
thus have their deps listed as devDependencies).
This PR adds an environment variable that should allow us to test the bundled version for Next.js on Vercel, see https://github.com/vercel/next.js/pull/52997 for reference.
The changes include:
- a new environment variable `VERCEL_NEXT_BUNDLED_SERVER`
- some logic changes that will put app route handlers into their own lambda groups
- extra logic to require early the rendering runtimes (see PR above for details)
The Ionic example has an actual Google Maps API key by default and we'd
like to not have it displayed, so we'll replace it with a placeholder
instead. Considering it's commented out anyways, this will be a no-op.
---------
Co-authored-by: Steven <steven@ceriously.com>
This ensures that the `.prefetch.rsc` requests respond with the correct `content-type` since this is used by Next.js to determine if a request is valid or not (and in the case it's invalid, an mpa navigation will occur)
Fixes: https://github.com/vercel/next.js/issues/54934
This adds an experimental flag to `Prerender` outputs as a way to programmatically bypass the cache and hit the lambda directly, using a similar interface to `has`.
(Note: I copied over `HasField` from `@vercel/router-utils` since it wasn't available for import in `build-utils`, but can add it as a dep if that's preferred)
The specific use-case being targeted here relates to https://github.com/vercel/next.js/pull/51534 -- a Next.js page marked static should still be able to initiate server actions.
The following error occurs during build when `basePath` is present in conjunction with `fallback: false` in `getStaticPaths`:
> Error: ENOENT: no such file or directory, open '/vercel/path0/.next/server/pages/404.html'
`localePrefixed404` was incorrectly being set to `false` because it was looking for `/<basePath>/<locale>/404.html` (when it's actually `/<locale>/404.html`)
This meant that inside `onPrerenderRoute`, `htmlFsRef` was pointing to `/404.html` rather than `/en/404.html`.
- Removes some of the hacks from #10388 that were attempting to resolve an issue with RSC prefetches to `pages` routes in favor of adding rsc rewrites for all dynamic paths, and letting it fall through to a 404 if there's no match
- Fixes an issue where RSC requests were matching the wrong path (filesystem rather than RSC variant) introduced in above mentioned change
- Closes https://github.com/vercel/next.js/issues/54698
Updates the `secrets` command to be a bit more modern. Initially I was going to covert this to typescript but that change was quite large, so going stepwise for easier review.
1. Moves the command implementation into a directory like other commands
2. Shifts the command data structure into its own file
3. Adds a test.
Other relevant comments inline.
The intention is for this to be a drop-in replacement for compiling TypeScript to JavaScript, but using `esbuild` instead of `tsc`. `tsc` is still needed, but only for the cases where we want to generate type definitions.
Addresses ReDoS vulnerability: https://security.snyk.io/vuln/SNYK-JS-SEMVER-3247795
Uses the latest unaffected versions in the respective major versions, to prevent having to deal with any other breaking changes.
The redwood template was broken because it would use node@18, which is not supported for the version of redwood used in the template. This PR updates that version to be node@16, which does work.
While we're at it, I also updated other examples to be at least node@16. I tested deployments of each of these and the all work.
# Problem
Framework authors often produce build outputs from platforms like Github
Actions or M1 Macs where the arm64 architecture is being used. They then
deploy these outputs to Vercel using `vercel deploy`, bypassing Vercel's
build system. Today they must cross compile to x86_64 in order to deploy
compatible Serverless functions to Vercel.
# Solution
Allow Framework authors to detect the current architecture and specify
either x86_64 or arm64 when deploying a Serverless function to Vercel.
# Related PRs
https://github.com/vercel/api/pull/21559https://github.com/vercel/proxy/pull/6901https://github.com/vercel/front/pull/24924
`vc secrets` appears to be mostly deprecated but this was a fairly straightforward change that lets us drop `mri` today. Tested pretty extensively locally.
Fixes two separate issues for the Next builder:
- `pages` routes unexpectedly matching to RSC routes when prefetching from `app`. This update will attempt to match the route with the corresponding `pages` entry rather than falling back to a catch-all RSC
- Fixes https://github.com/vercel/next.js/issues/53776
- `fallback: false` returning a successful status code when underlying page as a param (e.g. `/blog/[slug]` would 200 but `/blog/non-existent` would 404)
- [slack x-ref](https://vercel.slack.com/archives/C03S8ED1DKM/p1692817762403579)
The `supersedes` property on the `Framework` interface may be specified by a framework in which the superseded framework should _not_ be included in the resulting framework matches during detection.
For example, a Hydrogen v2 project matches both the "remix" and "hydrogen" framework detectors, but we really only want "remix" to be selected.
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@31.4.0
### Minor Changes
- Force-publish ([#10358](https://github.com/vercel/vercel/pull/10358))
### Patch Changes
- Updated dependencies
\[[`6e44757ff`](6e44757ff5)]:
- @vercel/static-build@1.4.0
## @vercel/static-build@1.4.0
### Minor Changes
- Force-publish ([#10358](https://github.com/vercel/vercel/pull/10358))
### Related Issues
Reported in https://github.com/vercel/community/discussions/194
Having the `-D` flag results in all draft content to be published (docs reference [here](https://gohugo.io/getting-started/usage/)).
### 📋 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
This PR updates the ember example using the following:
```
npx ember new ember-quickstart --lang en
```
I also had to add `{ 'ember-welcome-page': { enabled: true } }` to the
build config because the `<WelcomePage>` only works in dev, but throws
when using the default build command:
```
ember build --environment=production
```
For posterity, the error looks like:
```
Uncaught TypeError: Cannot destructure property 'manager' of 'e' as it is null.
at u.resolvedComponent (vendor-2e12520b7a71eead28708a24fafa7fbc.js:2094:28)
at vendor-2e12520b7a71eead28708a24fafa7fbc.js:1999:5
at ne (vendor-2e12520b7a71eead28708a24fafa7fbc.js:1999:30)
at l (vendor-2e12520b7a71eead28708a24fafa7fbc.js:1991:18)
at vendor-2e12520b7a71eead28708a24fafa7fbc.js:1981:836
at _.compile (vendor-2e12520b7a71eead28708a24fafa7fbc.js:1938:173)
at re (vendor-2e12520b7a71eead28708a24fafa7fbc.js:1991:61)
at vendor-2e12520b7a71eead28708a24fafa7fbc.js:1988:30
at ee.compile (vendor-2e12520b7a71eead28708a24fafa7fbc.js:1989:23)
at Object.evaluate (vendor-2e12520b7a71eead28708a24fafa7fbc.js:2431:224)
```
- Related https://github.com/emberjs/ember.js/issues/19912
- Related https://github.com/ember-cli/ember-welcome-page/issues/385
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@31.3.1
### Patch Changes
- Updated dependencies
\[[`844fb6e88`](844fb6e880)]:
- @vercel/remix-builder@1.10.1
## @vercel/remix-builder@1.10.1
### Patch Changes
- Set default env vars for Hydrogen v2 deployments
([#10341](https://github.com/vercel/vercel/pull/10341))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
In order to make the default mock shop created from `npm create @shopify/hydrogen@latest` work out-of-the-box and without additional configuration, set the necessary default environment variables to make the server not render an error.
# Summary
Edge-runtime 2.4.4 has many bug fixes, but most importantly it adds support for stream cancellation to the edge runtime. This is extremely important since a lot of projects are using `streams` related to `ai`. They currently have no way of handling a cancellation coming from the client.
This was introduced to `next` with as described by this comment: https://github.com/vercel-labs/ai/issues/90#issuecomment-1618915409
You can find the PR for that here: https://github.com/vercel/next.js/pull/51727
It also has a good description for what we're trying to do here, but for people not using `next`
# Problem
When a client sends an abort signal, it is currently not being handled by edge functions. This was fixed in edge-runtime@2.4.4
# Solution
Update the package
Follow-up to https://github.com/vercel/vercel/pull/10319, which didn't exhibit this failing test since the fs-detectors package was not changed, and thus those tests didn't run.
I erred on the side of preferring the more recently added versions of this behavior. I assume at some point in the distant past the removed function correctly toggled between some now/zeit/vercel transitioning.
Now that the "remix" preset should be used for Hydrogen v2, it's not very clear that the "hydrogen" preset is only meant to be used for Hydrogen v1.
So add clarification in the "name" of the "hydrogen" preset to help remedy that.
Adds a Hydrogen v2 template which is the output of the `npm create @shopify/hydrogen@latest` command.
Note that a `vercel.json` file is being used to define the environment variables that are required at runtime. This is required for the template to deploy with zero configuration, however the user should update these values (including replacing the session secret) and migrate them to the Project settings in the Vercel dashboard.
[Live example](https://hydrogen-v2-template.vercel.app)
`vc build` writes a file `.vercel/output/build.json` that contains the `argv` contents which could include sensitive information that needs to be sanitized.
Enables support for Hydrogen v2 apps using the "Remix" preset. This initial support works with the Hydrogen demo store template unmodified, and all pages will use Edge functions.
Node.js runtime, and also any other configuration via `export const config`, are not supported at this time, due to some pending blockers.
The current note on discussion templates is not bold enough and easily overlooked.
In an effort to reduce off-topic discussion clutter in this repo and direct folks to the general support community which I monitor more closely, this update makes the note more prominent.
When we upgraded `turbo`, the default `--log-order` changed from `stream` to `grouped`.
This PR changes it back to `stream` which will prevent the collapsed group view that we currently see in CI.
https://turbo.build/repo/docs/reference/command-line-reference/run#--log-order
> If log order is set to auto and turbo detects that it is running on GitHub Actions, then turbo will create grouped logs(opens in a new tab). You can opt out of this behavior by setting a log order of your own.
We noticed some edge function builds are failing unexpectedly due to `SyntaxError`. It's triggered by valid code in [Webpack's style-loader](16e401b17a/src/runtime/styleDomAPI.js (L35C1-L40C1)):
```
if (sourceMap && typeof btoa !== "undefined") {
css += `\n/*# sourceMappingURL=data:application/json;base64,${btoa(
unescape(encodeURIComponent(JSON.stringify(sourceMap)))
)} */`;
}
```
After minification this script looks like:
```
sourceMap&&typeof btoa!="undefined"&&(css+=`
/*# sourceMappingURL=data:application/json;base64,${btoa(unescape(encodeURIComponent(JSON.stringify(sourceMap))))} */`);
```
The key point here is `\n` is replaced with newline character (`0x0A`) and the second line starts with `/*# sourceMappingURL=`. This confuses `removeComments` API in [convert-source-map](https://github.com/thlorenz/convert-source-map/tree/master) package and it removes the second line:
```
sourceMap&&typeof btoa!="undefined"&&(css+=`
```
In this PR, we implement source map stripping based on that package's regex but add some heuristic checks to prevent false positives like above.
The Remix application might _also_ be the root of a workspace, so check for that case and pass the appropriate flag to the package manager to make it not error.
See: https://github.com/orgs/vercel/discussions/3467
I'm experiencing an issue due the condition is wrongly set.
When the response is buffered, it should be `compress: true` since we're acting as proxy, and we're going to recompress again.
When the response is streaming, then it should be `compress: false` since the response is going to be piped.
Instead of including the fork `@remix-run/dev` package as a regular dependency of `@vercel/remix-builder`, install it at build-time by modifying the project's `package.json` file. The reasons for this are:
* Avoids deprecation warnings from a few packages that currently exist on the `@remix-run/dev` package when installing Vercel CLI (those warnings already show up in the build logs anyways, so nothing new there).
* Allows us to install a version as close as possible to the version specified in the user's `package.json` (similar to how we do when auto-injecting the `@vercel/remix` package). This will be especially important once Remix v2 is released, which will have breaking changes compared to v1.
**Note:** `@vercel/remix-run-dev` is still a _dev_ dependency, so that we can use TypeScript types from it, as well as, at runtime, we use the version in the Builder's `package.json` to determine the maximum versions of `@vercel/remix-run-dev` and/or `@vercel/remix` which can safely be installed.
Fixes#10027.
Fixes#10222.
Followup PR to #10090. Some of our commands duplicate global options into their `args` structure e.g. 2661f56347/packages/cli/src/commands/logs.ts (L25-L26)
Others commands omit it entirely.
This updates the `--help` output for commands migrated to our new structure (so far, only `deploy`) will show a "Global Options" section:
```
▲ vercel deploy [project-path] [options]
Deploy your project to Vercel. The `deploy` command is the default command for the Vercel CLI, and can be omitted (`vc deploy my-app` equals `vc my-app`).
Options
--archive Compress the deployment code into a file before uploading it
-b, --build-env <key=value> Specify environment variables during build-time (e.g. `-b KEY1=value1 -b KEY2=value2`)
-e, --env <key=value> Specify environment variables during run-time (e.g. `-e KEY1=value1 -e KEY2=value2`)
-f, --force Force a new deployment even if nothing has changed
-m, --meta <key=value> Specify metadata for the deployment (e.g. `-m KEY1=value1 -m KEY2=value2`)
--no-wait Don't wait for the deployment to finish
--prebuilt Use in combination with `vc build`. Deploy an existing build
--prod Create a production deployment
-p, --public Deployment is public (`/_src`) is exposed)
--regions Set default regions to enable the deployment on
--with-cache Retain build cache when using "--force"
-y, --yes Use default options to skip all prompts
Global Options
--cwd <DIR> Sets the current working directory for a single run of a command
-d, --debug Debug mode (default off)
-Q, --global-config <DIR> Path to the global ${'`.vercel`'} directory
-h, --help Output usage information
-A, --local-config <FILE> Path to the local `vercel.json` file
--no-color No color mode (default off)
-S, --scope Set a custom scope
-t, --token <TOKEN> Login token
-v, --version Output the version number
```
As commands are migrated to this new structure, they'll gain this output automatically.
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@31.1.1
### Patch Changes
- Updated dependencies
\[[`7c30b13cc`](7c30b13ccb)]:
- @vercel/next@3.9.2
## @vercel/next@3.9.2
### Patch Changes
- Fix pages/404 gsp + i18n case
([#10258](https://github.com/vercel/vercel/pull/10258))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
# Releases
## vercel@31.1.0
### Minor Changes
- Add 'Environment' column to 'vc list' with new '--environment' filter
and pipe URLs to stdout
([#10239](https://github.com/vercel/vercel/pull/10239))
### Patch Changes
- Update `proxy-agent` to v6.3.0
([#10226](https://github.com/vercel/vercel/pull/10226))
- Use `getNodeBinPaths()` in `vc dev`
([#10225](https://github.com/vercel/vercel/pull/10225))
- Updated dependencies
\[[`b1c14cde0`](b1c14cde03),
[`ce4633fe4`](ce4633fe4d)]:
- @vercel/next@3.9.1
- @vercel/static-build@1.3.42
## @vercel/frameworks@1.5.0
### Minor Changes
- Add `ignorePackageJsonScript` configuration for Framework command
settings to ignore the `package.json` script.
([#10228](https://github.com/vercel/vercel/pull/10228))
Enable this mode for Storybook's `buildCommand`, since it should not
invoke the "build" script, which is most likely designated for the
frontend app build.
## @vercel/fs-detectors@4.1.1
### Patch Changes
- Updated dependencies
\[[`ce4633fe4`](ce4633fe4d)]:
- @vercel/frameworks@1.5.0
## @vercel/next@3.9.1
### Patch Changes
- Fix pages and app router i18n handling
([#10243](https://github.com/vercel/vercel/pull/10243))
## @vercel/static-build@1.3.42
### Patch Changes
- Add `ignorePackageJsonScript` configuration for Framework command
settings to ignore the `package.json` script.
([#10228](https://github.com/vercel/vercel/pull/10228))
Enable this mode for Storybook's `buildCommand`, since it should not
invoke the "build" script, which is most likely designated for the
frontend app build.
Also adds a new `--environment=[preview|production]` filter and ability to pipe deployment URLs to `stdout`!
<img width="380" alt="image" src="https://github.com/vercel/vercel/assets/97262/20de0caa-2d63-4112-8213-cc15d23295c7">
```
vc list --environment preview
```
```
vc list --environment production
```
```
vc list --environment preview > preview_deployments.txt
```
This allows for the "dev command" of a Project to work better in monorepos, where the dev server might live up the node_modules hierarchy within the repo.
When this property is set to `true`, then the corresponding `package.json` script will not be invoked, allowing for the default setting value will be executed.
This is enabled for Storybook's `buildCommand`, since we do not want the "build" script to be invoked, since that would belong to the frontend application's build instead of Storybook's.
This was supposed to be fixed in https://github.com/vercel/vercel/pull/10173 but the file was created after git commit.
This PR makes sure the file is created before git commit.
Follow up PR to
8703c55f9f
which reads the newly created function config manifest and patches in
the options for resource creation.
---------
Co-authored-by: Steven <steven@ceriously.com>
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/fs-detectors@4.1.0
### Minor Changes
- Add `detectFrameworks()` function
([#10195](https://github.com/vercel/vercel/pull/10195))
## @vercel/build-utils@6.8.2
### Patch Changes
- Push back `nodejs16.x` discontinue date to `2024-02-06`
([#10209](https://github.com/vercel/vercel/pull/10209))
## vercel@31.0.3
### Patch Changes
- Fix redeploy target to be undefined when null
([#10201](https://github.com/vercel/vercel/pull/10201))
- Respect forbidden API responses
([#10178](https://github.com/vercel/vercel/pull/10178))
- Update `supports-hyperlinks` to v3
([#10208](https://github.com/vercel/vercel/pull/10208))
- Updated dependencies
\[[`0750517af`](0750517af9)]:
- @vercel/build-utils@6.8.2
- @vercel/static-build@1.3.40
- @vercel/node@2.15.5
- @vercel/remix-builder@1.8.17
## @vercel/client@12.6.5
### Patch Changes
- Updated dependencies
\[[`0750517af`](0750517af9)]:
- @vercel/build-utils@6.8.2
## @vercel/gatsby-plugin-vercel-builder@1.3.13
### Patch Changes
- Updated dependencies
\[[`0750517af`](0750517af9)]:
- @vercel/build-utils@6.8.2
- @vercel/node@2.15.5
## @vercel/node@2.15.5
### Patch Changes
- Updated dependencies
\[[`0750517af`](0750517af9)]:
- @vercel/build-utils@6.8.2
## @vercel/remix-builder@1.8.17
### Patch Changes
- Updated dependencies
\[[`0750517af`](0750517af9)]:
- @vercel/build-utils@6.8.2
## @vercel/static-build@1.3.40
### Patch Changes
- Updated dependencies \[]:
- @vercel/gatsby-plugin-vercel-builder@1.3.13
## @vercel-internals/types@1.0.5
### Patch Changes
- Updated dependencies
\[[`0750517af`](0750517af9)]:
- @vercel/build-utils@6.8.2
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Similar to `detectFramework()`, but this version returns all detected frameworks at the given path. It also returns the full `Framework` objects instead of just the slug.
This will be useful for detecting when multiple Projects exist at the same root directory (i.e. Storybook).
**Note:** I rearranged some tests, so probably review with [whitespace changes hidden](https://github.com/vercel/vercel/pull/10195/files?diff=split&w=1).
This PR disabled `node-fetch` default compression handling when the
response is not streamed.
The default behavior in node-fetch is to handle the compression. That's
great if you interact with node-fetch as user, but bad if you use it as
intermediate proxy server, since it's creating a mismatching related
with the body format and length expectations.
Instead, we disable compression, get the buffered response and compress
it again if needed.
---------
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
This PR fixes customer issue
https://github.com/vercel/customer-issues/issues/1310 which identified
an issue with the `redeploy` command.
`redeploy` should not default the `target` to `'production'` as an
`undefined` target is meant to mean `'preview'`.
These packages already don't get published since they have `private: true`, but adding to the "ignore" configuration also removes them from the selection prompt when executing the `changeset` CLI command.
Previously, `createProject()` only allowed a string `name` to be provided, and another API call would need to be done after creation with `updateProject()`. This should not be necessary since the `POST` endpoint can accept additional properties already.
Reverts vercel/vercel#8681
We ran an experiment here a while ago but it had flaky results.
This PR cleans up the experiment code, and reverts to the previous behavior.
This PR adds a new utility for generating `help` output for CLI
commands. Backed by a JSON data structure that represents the commands,
this utility uses deterministic functions for generating the different
output sections (such as `options` and `examples`). This change will let
contributor easily add/modify command details. The data structure is
also used by the CLI to generate the args parsing structure for the
`deploy` command. Optimistically, this same data structure can be used
to generate documentation output for `front` such that the online docs
will match the `help` output.
---------
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
This will solve two of the warnings from [Socket.dev](https://socket.dev/npm/package/vercel):
<img width="1126" alt="image" src="https://github.com/vercel/vercel/assets/229881/c890c973-4f5a-44d9-9b96-2580a1e40ed0">
This preinstall script isn't necessary to run Vercel CLI, its only used to improve the error message in two cases:
- The system has `node` version prior to 14.x (3 years ago)
- The system still has `now` installed but should be using `vercel` (last shipped 3 years ago)
The usage of `preinstall` scripts have gone out of style due to security audits so we should remove this script now.
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@31.0.1
### Patch Changes
- Updated dependencies
\[[`aa734efc6`](aa734efc6c)]:
- @vercel/next@3.8.8
## @vercel/next@3.8.8
### Patch Changes
- [next] Ensure RSC paths handle basePath
([#10155](https://github.com/vercel/vercel/pull/10155))
The `getNodeBinPath()` function is problematic because it assumes that commands are installed in the `node_modules` directory alongside the detected lockfile. This works fine the majority of the time, but ends up not being the case when using a monorepo that uses a package manager in "linked" mode (i.e. pnpm by default).
Consider the following:
```
.
├── pnpm-lock.yaml
├── node_modules
├── blog
│ ├── node_modules
│ │ ├── hexo -> .pnpm/hexo@3.9.0/node_modules/hexo
```
In this setup, adding the root-level `node_modules/.bin` would not make the `hexo` command be visible in the `$PATH`.
To solve this issue, the new `getNodeBinPaths()` function returns an array of all directories up to the specified `root`, which can then be placed into the `$PATH`. It's also more efficient (synchronous) since it does not need to scan for a lockfile anymore (the `root` needs to be specified explicitly).
The new function is being used in `@vercel/next` and `@vercel/static-build`.
The `traverseUpDirectories()` function from CLI was moved to `build-utils` to implement this function. Consequently, that makes the implementations of `walkParentDirs()` and `walkParentDirsMulti()` simpler, since it's using this generator now.
In order to promote a preview deployment, we want to make sure the user knows that this is not typical. Now the `--yes` flag is required to make this work.
Production was recently changed to make redirect responses return the text "Redirecting..." without the destination nor status code in the text.
This caused some tests to start failing, so update `vc dev` to match this new behavior and update the relevant tests.
This changes the error when a token is invalid or expired from
```
Error: Could not retrieve Project Settings. To link your Project, remove the `.vercel` directory and deploy again.
Learn More: https://vercel.link/cannot-load-project-settings
```
to a better error
```
Error: The specified token is not valid. Use `vercel login` to generate a new token.
```
- This could be considered a follow up to
https://github.com/vercel/vercel/pull/7794
`LocalFileSystemDetector#readdir()` was throwing an error when a symlink was encountered, due to `fs.readdir()` `withFileTypes: true` option performing an lstat instead of a stat operation.
So re-implement the `readdir()` logic to use `fs.stat()` so that the symlink is resolved (only "dir" and "file" types are expected in the result).
When showing the Project selector and there's more than one Project matched given the current cwd, only show the matched Projects instead of all Projects listed in the `repo.json` file.
When `vc deploy` happens, it was forcing a `true`/`false` value for `autoAssignCustomDomains`. This overwrites the project setting in some cases, which is not what we want.
If a CLI command or API call explicitly wants to force `autoAssignCustomDomains` on or off, it can. Otherwise, the project setting value should be used.
This PR only sets `autoAssignCustomDomains` to `false` when the `--skip-domain` flag is passed. Otherwise, the value is `undefined` so that the project setting can take effect.
The code for these two are almost identical, so consolidate into one codebase.
Also adjusts the `pnpm test` script to allow for specifying a file name to be executed, instead of running all tests.
Superceded by the `findProjectsFromPath()` function which may return multiple matches, and it was only being used in tests.
The relevant tests have been updated to use the multiple matches version instead, and updated to include the case where multiple matches are returned.
__Note:__ No changeset for this one since it's an internal function being removed, and doesn't need to be referenced in the public changelog.
When repo linked, `vc deploy --prebuilt` will change working directory to the Project root directory, instead of the repo root, so that the project's local `.vercel/output` directory is what gets uploaded + deployed.
This is a follow up to PR #9892 which changed the default to `.env.local`.
Now that we know local files should never be committed to git, we can automatically add `.env*.local` to `.gitignore`. Note that this is the same ignore pattern that ships with create-next-app [as seen here](06abd63489/packages/create-next-app/templates/app/js/gitignore (L28)), so most Next.js users won't see anything change.
See the related [Linear ticket](https://linear.app/vercel/issue/VCCLI-461/)
ncc has an issue with detecting + rewriting this file path for some reason. Moving to a helper function should work around that issue.
Fixing:
```
Error: ENOENT: no such file or directory, open '/node_modules/vercel/projects/VERCEL_DIR_README.txt'
```
When repo linked, `vc dev` already works fine when run from the root of the repo. This change makes it so that `vc dev` also works as expected when executed within a project subdirectory.
When the repo is linked to Vercel with `vc link --repo`, the `vc build` command should be invoked from the project subdirectory (otherwise the project selector is displayed). The output directory is at `<projectRoot>/.vercel/output` instead of at the repo root.
When no content type header is sent to an API request during `vc dev`, the request fails:
```
/Users/smassa/source/vercel/vercel-2/node_modules/.pnpm/content-type@1.0.4/node_modules/content-type/index.js:108
throw new TypeError('argument string is required')
^
TypeError: argument string is required
...
```
This comes from some runtime type validation happening in the `content-type` package, for which we do not have types, which is why typescript didn't catch this.
When the repo is linked to Vercel with `vc link --repo`, the `.vercel` directory will be created at the _project root_ instead of the _repo root_, and will still contain the `project.json`.
The difference is that the `orgId` and `projectId` props will not be present in the `project.json` file when repo linked, since that information is available at the root level `repo.json` file.
Adds async iterator helper function for interacting with endpoints that have pagination.
Implemented for use with `vc bisect` (fetching deployments) and `vc link --repo` (fetching projects).
When a project has a `.npmrc` containing `use-node-version`, package managers (notably `pnpm`) will download the specified Node.js version. This is not the correct way as it can lead to `pnpm` downloading Node.js 18 or newer which depends on a version of GLIBC that is not present in the current AWS image. The proper way is to set the `"engines"` in the `package.json`.
<img width="468" alt="image" src="https://github.com/vercel/vercel/assets/97262/0974cf05-6a11-4d95-88e8-13affc4aad2a">
Discussion: https://github.com/orgs/vercel/discussions/2436
### Description
This ensures the Summary job always runs to check if any test failed and
cause itself to fail as well.
This allows us to dynamically add as many concurrent jobs as we want but
only have one (Summary) marked as required.
### Testing
I verified this worked by making a change to `@vercel/static-config`
which is not required and the Summary check failed:
https://github.com/vercel/vercel/actions/runs/5136560652/jobs/9243924596
Then I reverted it so that the test was passing and the Summary check
passed:
https://github.com/vercel/vercel/actions/runs/5137401343/jobs/9245554297
This is a re-application of #10022 (which was reverted in #10032), but with the addition of `changeset tag` after the `pnpm publish -r` command. This ensures the proper git tags are also created, allowing for the GitHub releases to be published.
A few commands were still checking on `--cwd` explicitly, which is incorrect since the entrypoint file already handles the directory change.
The new `client.cwd` property is a helper to make writing tests easier. Tests no longer need to `chdir()` explicitly and then revert afterwards.
This reverts commit 1e47bbf32f.
`changeset publish` also creates git tags, whereas `pnpm publish -r` does not. This causes the GitHub Releases to not be created.
Right now, we can't detect API routes correctly if `pageExtensions` is set:
> WARNING: Unable to find source file for page xxxx with extensions: js, jsx, ts, tsx, this can cause functions config from `vercel.json` to not be applied
We added appDir support in https://github.com/vercel/vercel/pull/9811 so that users can customize `memory`/`maxDuration` for routes in appDir.
But since RSC is enabled by default in Next.js 13, `vercel build` still reports some warning messages, such as:
```json
"functions": {
"app/**/*": {
"maxDuration": 5,
"memory": 512
}
}
```
```
WARNING: Unable to find source file for page hello.js with extensions: ts, tsx, js, jsx, md, mdx, this can cause functions config from `vercel.json` to not be applied
WARNING: Unable to find source file for page index.js with extensions: ts, tsx, js, jsx, md, mdx, this can cause functions config from `vercel.json` to not be applied
```
To suppress these errors and properly apply `functions` setting to those routes, updating the current detection logic to also search `page.${ext}` files.
This PR removes dependency on the deprecated `lastRollbackTarget` project property and adopts many of the code conventions used in `vc promote`.
Important! Please merge #9984 first!
Hey team,
I had an error this morning when trying to link my repo using the CLI
Seems like a combination of `: any` and a recent refacto introduced an issue here.
~- Removed all `any` that were hiding the error~
- Correctly pass the URL already parsed
~- Removed the second useless parsing~
~- Added missing `--help` flag~
~I noticed you never specify them and Typescript screams because of that, not sure if on purpose and how you make the compilation pass with this error. Don't hesitate to tell me.~
The fix could be improved by using `arg.Result<THE_ACTUAL_TYPE>` but that would require to store the dictionnary of flags somewhere else and also create an external type. This is already better so...
---
NB:
I had multiple issues while cloning this repo
- pnpm bootstrap does not work
- missing `constants.ts` file that is not explained in the Contributing guidelines
- maybe due to bootstrap not working, almost nothing else worked and the tests too.
Some of these packages got out of sync at some point, causing duplicate
/ older copies to be installed. Additionally, the `@vercel-internal`
packages should have "version" fields.
Attempting to fix these
[warnings](https://github.com/vercel/vercel/actions/runs/5048844603/jobs/9057538600)
during release:
```
Package "examples" must depend on the current version of "@vercel/frameworks": "1.4.2" vs "1.3.0"
Package "@vercel-internals/constants" must depend on the current version of "@vercel/build-utils": "6.7.3" vs "6.3.2"
Package "@vercel-internals/constants" must depend on the current version of "@vercel/routing-utils": "2.2.1" vs "2.1.10"
Package "@vercel-internals/constants" must depend on the current version of "@vercel-internals/tsconfig": "undefined" vs "*"
Package "@vercel-internals/get-package-json" must depend on the current version of "@vercel-internals/tsconfig": "undefined" vs "*"
Package "@vercel-internals/types" must depend on the current version of "@vercel-internals/constants": "undefined" vs "*"
Package "@vercel-internals/types" must depend on the current version of "@vercel/build-utils": "6.7.3" vs "6.3.2"
Package "@vercel-internals/types" must depend on the current version of "@vercel/routing-utils": "2.2.1" vs "2.1.10"
Package "@vercel-internals/types" must depend on the current version of "@vercel-internals/tsconfig": "undefined" vs "*"
Package "vercel" must depend on the current version of "@vercel-internals/constants": "undefined" vs "*"
Package "vercel" must depend on the current version of "@vercel-internals/get-package-json": "undefined" vs "*"
Package "vercel" must depend on the current version of "@vercel-internals/types": "undefined" vs "*"
Package "@vercel/node" must depend on the current version of "@vercel/error-utils": "1.0.10" vs "1.0.8"
```
`vc deploy` ignores `.env.local`. To make sure we don't inadvertently
push people's secrets to source control, have all environment pulls
default to writing to `.env.local`.
Removes the unused `--platform-version` flag from the common args.
Technically this is a breaking change, so we should probably hold off on merging until we plan to do a major version bump.
The logic to retrieve the latest release was not working correctly, so use the `getLatestRelease()` function instead of assuming that `release[0]` is tagged as the latest.
In a Next.js app, if you have Node.js Functions in both `api` and `pages/api`, you'll get a warning about moving those `api` functions into `pages/api`. This does specify Node.js Functions already, but a user was confused and tried to move their non-Node.js functions into `pages/api` as well.
This PR tries to make it clearer that you can do both. Note that this still requires a non-ideal local dev setup where you:
- update next config to fall back to the `vc dev` port for `api` handlers
- run `next dev` for the Next.js app on one port
- run `vc dev` for the top-level `api` Functions on another port
---
Example repo: https://github.com/rexfordessilfie/vercel-api-languages
Adding a new `--repo` flag to `vc link` which is a new linking style to
link to a Git URL rather then directly to a single Vercel Project. This
allows for multiple Projects to be linked simultaneously, which is
useful for monorepo setups.
Utilization of this new linking style in other commands will be done in
a follow-up PR.
There is an issue where you can interrupt a gatsby project build and the temporary files are not cleaned up. If you try to build again, it will get stuck in an infinite loop.
This PR adds an exit hook to make sure the cleanup happens.
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@29.3.4
### Patch Changes
- Updated dependencies
\[[`67e556bc8`](67e556bc80),
[`ba10fb4dd`](ba10fb4dd4)]:
- @vercel/remix-builder@1.8.9
- @vercel/next@3.8.4
## @vercel/next@3.8.4
### Patch Changes
- Update handling for react prebundled flag
([#9974](https://github.com/vercel/vercel/pull/9974))
## @vercel/remix-builder@1.8.9
### Patch Changes
- Upgrade `@remix-run/dev` fork to v1.16.1
([#9971](https://github.com/vercel/vercel/pull/9971))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
This ensures we properly set the prebundled react flag conditionally for
app and pages ensuring they are kept separate when bundling.
x-ref: https://github.com/vercel/next.js/issues/49169
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@29.3.3
### Patch Changes
- Updated dependencies
\[[`6c6f3ce9d`](6c6f3ce9d2)]:
- @vercel/next@3.8.3
## @vercel/next@3.8.3
### Patch Changes
- Ensure un-necessary rsc routes are not added
([#9963](https://github.com/vercel/vercel/pull/9963))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
It's possible that changesets will promote a release to latest that is
not the Vercel CLI release. This script ensures that a `vercel@` release
is always the latest after a publish happens.
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@29.2.1
### Patch Changes
- Updated dependencies \[[`6d5983eaa`](6d5983eaae)]:
- @vercel/remix-builder@1.8.8
## @vercel/remix-builder@1.8.8
### Patch Changes
- Upgrade `@remix-run/dev` to v1.16.0-patch.1 to fix erroneous "not found in your node_modules" warning ([#9930](https://github.com/vercel/vercel/pull/9930))
Partial revert of #9932, since apparently [that didn't
work](https://github.com/vercel/vercel/actions/runs/4941266637/jobs/8833725828).
We can investigate that more later, but this gets it working again
properly at least.
Also use Svelte's changelog generator, since it includes the PR numbers
which Sean wanted.
* Have changesets create the release PR as "Vercel Bot", so that the
tests run.
* Remove the `CHANGELOG.md` files. They are redundant with the GH
Releases which contain the same information.
`changesets` will improve our release workflow, since we will no longer need to manually curate and publish the changelog and GitHub Release. Instead, you simply merge the publish PR that the changesets GH action maintains as we push commits to `main`.
# Vercel CLI Extensions
Adds a new mechanism to add additional sub-commands to Vercel CLI, inspired by how Git handles sub-commands:
* Extensions are standalone executables that Vercel CLI will spawn as a child process.
* The name of the executable must begin with `vercel-`. For example, to add a sub-command called `vercel example`, there should exist an executable called `vercel-example`.
* The executable can either be a npm package with a `"bin"` entry installed into the local project's workspace, or be globally available in the `$PATH`.
* Extensions can access the [Vercel REST API](https://vercel.com/docs/rest-api), pre-authenticated, by utilizing the `VERCEL_API` env var. Vercel CLI spawns a local HTTP server that adds the `Authorization` header and then proxies to the Vercel REST API.
## Environment Variables
A few environment variables which provide features and context to the extension:
| Name | Description |
| ----------- | ----------- |
| `VERCEL_API` | HTTP URL to access the pre-authenticated Vercel API. |
| `VERCEL_TEAM_ID` | Provided when the currently selected scope is a Team. |
| `VERCEL_DEBUG` | Provided when the `--debug` flag is used. The command _may_ output additional debug logging. |
| `VERCEL_HELP` | Provided when the `--help` flag is used. The command _should_ print the help output and then end with exit code **2**. |
## Example
```bash
#!/usr/bin/env bash
set -euo pipefail
echo Hi, from a Vercel CLI Extension!
user="$(curl -s "$VERCEL_API/v2/user" | jq -r .user.username)"
echo "Logged in as: $user"
```
Usage:
```
$ vc example
Vercel CLI 28.18.5
Hi, from a Vercel CLI Extension!
Logged in as: tootallnate
```
When getting help output for the default command `vc --help`, you get a list of commands. When you specify the `deploy` command with `vc deploy --help`, you get the same list of commands.
This PR makes a distinction between an explicit `deploy` command and a default one for the purposes of help output.
Should show CLI help:
- `vc -h`
- `vc --help`
- `vc help`
Should show `deploy` command help:
- `vc deploy -h`
- `vc deploy --help`
- `vc help deploy`
When looping over the response headers returned by `node-fetch`, it will join `set-cookie` header value into a single string. The whatwg calls for a `headers.getSetCookie()` function to handle the `set-cookie` special case, but `node-fetch@2.x` doesn't support it.
As a workaround, we need to grab the raw `set-cookie` header value.
The `WebSocket` constructor exposed by `undici` is not working against some db connections.
That can be considered kind of expected since `undici` docs is saying it's experimental.
We're working into isolate the issue and report at `undici` repository, but for now, let's just use `ws` for all the node versions.
Currently, any warnings logged when calling `readConfig()` are emitted in build logs _three times_:
1. When initially reading the config before executing the Build Command
2. When the Build Command is executed (`remix build` reads the config)
3. After the build, in the `prepareCache()` function
For the callsites that we are in control of (`1.` and `3.`), we should suppress those warnings and only allow the standard warnings when invoking `remix build` to be emitted to the build logs.
`ignoreRuntimes: ['@vercel/node']` will also disable root-level middleware, which is not intended. So ensure that middleware still work, even for frameworks that have this `ignoreRuntimes` configuration enabled (Remix, RedwoodJS).
Adds `home` and `global` as supported values for `regions` when coming
from Next.js. We'll port these to the build output API at a later time.
Related Next.js changes: https://github.com/vercel/next.js/pull/48959
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This PR exposes `WebSocket` to be used for Edge Runtime for `vc dev`.
Ideally, that's a thing we should to handle inside `edge-runtime`
dependency.
Unfortunately, that is not as easy as it sounds, since Edge Runtime is
doing a heavy use of vm module and `undici` is using some Node.js APIs
that are not available, or they are hard to make them working inside vm.
Related PR: https://github.com/vercel/edge-runtime/pull/309
While we're finishing that work, in order to don't delay users to start
using `WebSocket`, we can simply expose it directly from `undici` as
dependency.
---------
Co-authored-by: Chris Barber <chris.barber@vercel.com>
When `@vercel/node` was created 5 or so years ago, Node.js didn't support ESM out of the box. So to create a zero configuration experience, babel was introduce to compile the authored ESM into the runtime CJS.
Today, Node.js supports ESM but you have to opt in using `type: module` in package.json or the `.mjs` file extension.
Indeed `@vercel/node` detects ESM and skips babel compilation. However, there is a case where the source code is ESM and a dependency supports both ESM and CJS via `imports` in package.json. This case will break because `@vercel/nft` traces the source file as ESM and assumes the dependency will be resolved as ESM too. But after `@vercel/nft` traces the source file, `@vercel/node` will compile to CJS and thus the trace will be incorrect and fail at runtime.
So this PR adds a warning when babel compiles ESM to CJS because it is no longer expected in 2023.
Currently, `functions` property (i.e., `memory` and `maxDuration`) are
not supported in appDir routes. This PR attempts to add support.
---------
Co-authored-by: Chris Barber <chris.barber@vercel.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
We want to keep the currently unused `runtime: "nodejs"` value clear for future use. This PR effectively makes any unrecognized value fail the build. If the value is "nodejs" specifically, a direct error is thrown suggesting they remove the value.
Only a handful of projects set this value currently. We're reaching out to them to let them know that this value is not currently supported and that they should remove it. Then, we should deploy this PR so that anyone else using this value will know to remove it.
It doesn't make sense to have `--target` as a global argument, because not all subcommands utilize this flag (actually only `vc deploy` does, and it's even deprecated).
This is technically a breaking change (though risk of someone using this flag on non-`vc deploy` is very unlikely), so we may want to hold off on merging this until we're ready to do a major version bump.
Right now, @Kikobeats is a required approver on `packages/node`. This change allows them to approve changes to the package without being absolutely required.
Log state validation errors, because they can be user error.
Example:
```
error "gatsby-node.js" threw an error while running the onPostBuild lifecycle:
Gatsby state validation failed:
- Expected boolean, got string ("true") at path "/redirects/0/isPermanent"
Please check your Gatsby configuration files, or file an issue at https://vercel.com/help#issues
3 |
4 | export const onPostBuild = async ({ store }: { store: any }) => {
> 5 | await generateVercelBuildOutputAPI3Output({
| ^
6 | // validated by `pluginOptionSchema`
7 | gatsbyStoreState: store.getState(),
8 | });
```
This enables the CLI to pass locally detected git meta data even when there is no available remote. It requires a corresponding internal change, which is blocking the e2e tests.
Until now, the user code response it's buffered and serialized. This is
mismatching how Vercel works these days.
This PR enables streaming response in `vc dev` for Edge/Serverless.
As part of the implementation, the `node-bridge` which spawns a process
to consume the user code is not necessary anymore.
Some necessary files (like HTTP server helpers) have been moved to live
in node builder package instead.
---------
Co-authored-by: Ethan Arrowood <ethan.arrowood@vercel.com>
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
The next-local e2e tests where split between middleware (fast) and all other (slow) tests. This meant there was not a good balance of amount of time spent across these test files, making overall test run times as slow as "all other tests" running.
This PR rebalances the split of tests across 2 files. The new run time is ~9-10m.
`@vercel/node` uses `ncc` to bundle the `index.js` spawns the dev server entrypoint which does not bundle the required dependencies, thus `path-to-regexp` and `ts-morph` must be moved from dev dependencies to dependencies.
Fixes#9735.
There's a need to allow `vc deploy` to not block and not wait for the deployment to finish, yet return the URL.
```
$ vc deploy --no-wait
Vercel CLI 28.18.5
🔍 Inspect: https://vercel.com/chrisbarber/next13fun/L8X4oxp5LGcmy51yVptXwMK7n4wt [1s]
📝 Note: Deployment is still processing...
✅ Production: https://next13fun-kecpx6za2-chrisbarber.vercel.app [1s]
```
Normally this deployment takes around 30 seconds, but the `--no-wait` flag causes the command to exit in less than 2 seconds.
The next step is to add the ability for `vc inspect` to wait as well as specify the maximum time to wait (defaults to 3 minutes, same as `vc rollback`).
```
$ vc inspect --wait --timeout 1m https://next13fun-kecpx6za2-chrisbarber.vercel.app
Vercel CLI 28.18.5
> Fetched deployment "next13fun-ov2r4pvdz-chrisbarber.vercel.app" in chrisbarber [23s]
General
id dpl_9VUuV23EGeoqWf7akEeL8rP1c8cb
name next13fun
status ● Ready
url https://next13fun-ov2r4pvdz-chrisbarber.vercel.app
created Thu Apr 13 2023 12:25:07 GMT-0500 (Central Daylight Time) [24s ago]
<snip>
```
Also added the ability to pipe the URL into `vc inspect`:
```
echo https://next13fun-ov2r4pvdz-chrisbarber.vercel.app | vc inspect
```
Combined, it allows us to support cool things like:
```
$ vc inspect $(vc deploy --prod --no-wait) --wait
```
- Creates new internals package, `@vercel-internals/constants`
- Refactors the `enum`s from `@vercel-internals/types` into `as const` objects, and moves them to `@vercel-intenrals/constants`
- Updates all relevant code within `packages/cli`, including `@vercel-internals/types` imports to be `import type`
This PR fixes a few issues related to `vc dev`.
1. Create a default `go.work` file in the cache dir when building the `vercel-dev-server-go` executable
2. Copy the existing `go.mod` file into the cache dir and update any "replace" relative paths
3. Split the "build" logic into separate functions for the legacy "main" package build and the `go.mod` build
Additionally, it fixes:
1. `vc build`: pass in `build.env` from `vercel.json`
2. Fix several tests to work with `vc dev` and `vc build`
Linear: https://linear.app/vercel/issue/VCCLI-638/vc-dev-go-builder-cant-resolve-workspace-dependencies
The user that reported the issue has tested this build and seems to fix their use case: https://github.com/vercel/vercel/issues/9393#issuecomment-1490726785.
Fixes an edge case in `parseRepoUrl()` when there is a `.com` in the repo name. The code was hard to refactor in its previous form so I refactored it to be simpler as well.
Before, we were stripping off only the hostname portion of `assetPrefix`, so any pathname was still being "handled" by the plugin.
Instead, we should be ignoring the `assetPrefix` entirely, so that these two configurations are treated differently:
* `{ assetPrefix: 'http://example.com', pathPrefix: '/foo' }` - Gatsby project is served from `/foo`
* `{ assetPrefix: 'http://example.com/foo', pathPrefix: undefined }` - Gatsby project is served from the root `/`
Currently, both configuration behave as the first version listed above. This change makes it so they can behave differently, specifically for some proxy configurations.
In both cases, the generated HTML contains the full URL `http://example.com/foo/*` for JS/CSS/etc. assets
Adds a new package under `scripts/internal-dependency-trace` that can be used to generate a rendering of any internal file dependency graph.
Default configured to generate the directed dependency graph of `packages/cli/src/index.ts`
This demo now showcases:
- `/` - A static page (pre-rendered)
- `/ssr` - A page that uses server-side rendering (through Vercel Edge Functions)
- `/ssr-with-swr-caching` - Similar to the previous page, but also caches the response on the Vercel Edge Network using `cache-control` headers
- `/edge.json` - An Astro API Endpoint that returns JSON data using Vercel Edge Functions
The new example has been deployed to https://astro.vercel.app.
Adds a new Route property called `isInternal` that indicates whether or not this is a project route or a Vercel platform route. Routes with this flag will be hidden from project-specific lists of routes to avoid confusion.
Verified on staging.
Minimatch 3.0.4 has a [ReDoS
vulnerability](https://security.snyk.io/vuln/SNYK-JS-MINIMATCH-3050818).
While not likely to be an issue for the packages that use it here, a
simple version bump should prevent the issue and reduce vulnerability
noise on audits. 3.1.2 is the latest version within the 3.x range, so
prevents breaking changes.
Follow-up to #9696. Ensures that all packages in this repository have
the correct "license" field in their respective `package.json` files set
to "Apache-2.0", to match the `LICENSE` file at the root of the
repository.
The `LICENSE` file the authoritative source, so the "MIT" value was
incorrect. This change corrects the previous values and is not
considered a relicensing.
Extracts the logic from `pkg.ts` into a new utility function
`getPackageJSON` from `@vercel-internals/utils`.
---------
Co-authored-by: Nathan Rajlich <n@n8.io>
Some unit tests didn't run since Aug 2022 because they are not included as part of the testing command.
This PR introduce `unit` and `integration` folders for testing, so anything that it's placed there will be run as part of the testing command.
Welcome to the grand splitting of CLI integration tests:
- replaced `test-cli` test suite with `test-e2e`
- made some small fixes along the way
- split integration tests into 3 files
- moved shared logic to `packages/cli/test/helpers/*`
- simplified `_execa` / `execa` / `execute` usage into `execCli` and `exec`
- simplified arguments required to make these work
- defaulted `execCLI` to set `NO_COLOR=1` to make assertions simpler in tests that aren't testing color/emoji support
- expanded functionality of `formatOutput` to handle error states
- centralized temp dir handling and cleanup
- enhanced `waitForPrompt` to:
- more clearly show what it was waiting for
- support waiting for regex, string, or a function that returns a boolean
- show what was the most recent thing it saw
- end early if the process it's monitoring exits
- removed some test pollution where unnecessary, shifted some into `beforeAll`
- renamed unit tests helper from `setupFixture` to `setupUnitFixture` to avoid confusion with the new shared helper `setupE2EFixture`
Some of this could be pulled out into a separate PR, but the feedback cycle is a slog, which this PR is helping to address. I'd be happy to discuss what could be pulled out, but I'd also be happy to get the whole thing through.
---
Wait for prompt failures:
<img width="939" alt="CleanShot 2023-03-27 at 10 24 21@2x" src="https://user-images.githubusercontent.com/41545/227987773-a3582549-32f9-4131-8a35-7be7cc265b66.png">
---
Current Timing:
```
Tests / test-e2e (vercel, 1, ubuntu-latest) (pull_request) Successful in 3m
Tests / test-e2e (vercel, 2, ubuntu-latest) (pull_request) Successful in 8m
Tests / test-e2e (vercel, 3, ubuntu-latest) (pull_request) Successful in 8m
```
---
Before merge, I'll mark the original `CLI` integration test suite as no longer required.
The `handleRequest()` function has been moved to the `@vercel/remix` package, so we can deprecate `@vercel/remix-entry-server` entirely and install `@vercel/remix` in the project instead, when there is no `app/entry.server.tsx` file defined in the project already.
Some condition in the system caused `BUILD_UTILS_SPAWN_1` errors to be thrown for failed deployments. The error handling logic wasn't handling this properly, causing the error message to never show up in the output.
```
Error: Unexpected error. Please try again later. ()
```
This PR fixes a handful of Go builder issues all related to the selected Golang version being used to build the function:
- `go.mod` version ignored for `vc build` and `vc dev`, uses system `PATH` version only
- `vc dev` fails if `go.mod` does not exist
- If the analyze bin doesn’t exist, downloads golang into `.vercel/cache/golang` instead of a global shared dir
- When running `vc dev`, doesn’t reuse go build code/common settings
- go tidy fails when `go.mod` set to 1.19 or 1.20, but 1.18 or older is installed
- `vc build` builds wrong arch on Apple Silicon/arm64
- `vc build` on Windows doesn't properly resolve "builds" in `vercel.json` due to posix separator issue
- `vc build` on Windows fails with `package <pkg/name> is not in GOROOT` due to posix separator issue
- Removed `actions/setup-go` from all test workflows
I added a test that tests the `go tidy` issue.
As reported https://github.com/vercel/vercel/discussions/9648, `vc build` does not honor the `--local-config <file>` option.
`vc build` will only load the `vercel.json` (or `now.json`) in the `workPath` which is based on the `rootDirctory`.
If `--local-config` is specified in the command line arguments, then it should take precedence.
When creating the `./vercel/output/static` dir...
**Moving the `public` dir** is what currently happens. This causes Gatsby to believe that the build was not complete:
> info We've detected that the Gatsby cache is incomplete (the .cache directory exists but the public directory does not). As a precaution, we're deleting your site's cache to ensure there's no stale data.
**Copying the `public` dir** is not an option because it can cause a build to run out of space.
**Symlinking the `public` dir** would work, but it would require more changes throughout the system to make sure the symlink was followed properly.
**Hard Linking the `public` dir's files** is the best option. This PR links the directories instead of moving them. We did look for a library that already does the `hardlinkFileTree` thing, but couldn't find one.
---
**Testing**
This was manually tested with real deployments.
---
* paired with @TooTallNate
* [user report](https://github.com/vercel/vercel/issues/9452#issuecomment-1432858615)
This PR is some cleanup before splitting python e2e tests.
Changes:
- use `probes.json`
- use `/api` autodetection instead of `builds` array
---
I was also trying to figure out why these tests are so much faster when run locally (293s) vs. CI (1099s). I encountered issues trying to view the build logs for the deployments that are made.
Remix v1.14.0 added support for having no `app/entry.server.tsx`/`app/entry.client.tsx` files in a project (there are default versions bundled into `@remix-run/dev`). Projects configured like this are currently failing because we symlink our forked version of the `remix` CLI into the project, so it cannot resolve the necessary modules at build time.
To solve this, instead of relying on the default versions of these files in `@remix-run/dev` package, we'll include our own versions in `@vercel/remix`, and physically copy them into the project dir. This way, the modules used will be properly resolved relative to the project's own `node_modules` dir.
Our default version of `app/entry.server.tsx` is also slightly different then upstream one, because it uses `@vercel/remix-entry-server` to enable isomorphic React streaming on both Node + Edge runtimes. Because of this, if that dependency is not present, then we'll automatically install the dependency at build-time.
In a previous PR (#9615) the unit tests were moved to separate jobs in
the `test.yml` workflow. So we can now change the `test-unit.yml`
workflow to simply be `test-lint.yml` to avoid redundancy.
I also checked to see if this would affect code coverage but it turns
out codecov was [disabled a long time
ago](https://app.codecov.io/gh/vercel/vercel).
- Creates `@vercel-internals/tsconfig`
- Changes `@vercel-internals/types` to depend on `@vercel-intenrals/tsconfig`
- Creates `@vercel-internals/utils`
Moving these to another PR:
- ~Moves all top level util files from `@vercel/cli` to `@vercel-internals/utils`~
- ~Updates all relevant imports within `@vercel/cli` to use `@vercel-internals/utils`~
Moves the type file out of the cli package and into its own standalone
package. utilizes `@vercel/style-guide` too for typescript config,
eslint, and prettier.
Next.js will pass the original middleware matching routes through to the middleware manifest once https://github.com/vercel/next.js/pull/46753 lands. This PR will take those original values and put them in the middleware route `middlewareRawSrc` property.
NOTE: The tests will need to be updated once the Next.js version is updated in the fixtures.
The "gatsby" dependency is large and relies on native packages ("sharp" specifically, which are error prone because it attempts to download a precompiled binary, of which the CDN has been down before causing us to not be able to merge anything).
The package is only used for TypeScript types, and we've decided that including the package only for those types is not worth the trouble. The existing JSON schemas already validate at runtime that the Gatsby redux store provides the values that we depend on.
`ajv` was ditched in favor of TypeBox types, which provide both JSON Schema and validation using a simpler syntax.
In Remix routes, you can [use bracket notation to escape the filesystem routing behavior](https://remix.run/docs/en/1.14.0/file-conventions/routes-files#escaping-special-characters). For example `app/routes/receipt[.]pdf.tsx` would be available at path `/receipt.pdf` (whereas, unescaped, it would be at `/receipt/pdf`).
This adds an e2e test for that behavior.
Move the try/catch block to immediately after the symlink call, so that if reading the `remix.config.js` file throws an error or if there's an error parsing the `export const config` in a route, the catch block will clean up after itself properly.
I recommend reviewing with [whitespace changes hidden](https://github.com/vercel/vercel/pull/9595/files?w=1).
Changes the way that routes with optional params are stored on Vercel to not use `?` in the name, because it's not possible to have a route destination with a `?` that's pointing to a function.
So instead of the function with a name such as `:lang?`, it will be stored on Vercel with a name like `(:lang)`, which can be routed to.
Show a more helpful message instead of showing a cryptic error messsage:
> Error: ENOENT: no such file or directory, copyfile
'/var/task/node_modules/@vercel/remix/server-node.mjs' ->
'/vercel/path0/packages/web/build/server-node.mjs'
This is probably due to a bad user configuration (i.e. with Turbo), but
tell them to contact support anyways in case there is a different cause
that we would need to address.
Apply the `regions` configuration (for both Edge and Node) and `memory`/`maxDuration` (only for Node) in a page's static config export, i.e.
```js
export const config = { runtime: 'edge', regions: ['iad1'] }
// or for Node
export const config = { runtime: 'nodejs', regions: ['iad1'], maxDuration: 5, memory: 3008 }
```
Similar to `runtime`, these config values can be inherited from a parent layout route to apply to all sub-routes. Routes with common config settings get placed into a common server bundle, meaning that there may now be more than 2 functions created (previously was one Edge, one Node), allowing for more granularity between the server build bundles.
Utilize the [`serverBundles`](https://github.com/remix-run/remix/pull/5479) config option to generate two server bundle builds. One contains only the routes that should run in Node.js, and the other contains only the routes that should run in the Edge runtime. In the future we could update this configuration to generate more than two bundles to be more granular and allow for infinite scalability.
Because the `serverBundles` PR is not yet merged, this PR introduces usage of a forked version of `@remix-run/dev` which incorporates our changes. Hopefully usage of a fork is temporary, but it gets us unblocked for now.
Makes it easier to test fixtures directly via CLI deployments.
Coincidentally, this also revealed that auto-detection of Remix apps wasn't working correctly if there's a `remix.config.mjs` file. So `@vercel/frameworks` is updated to account for that case as well.
Fixes an edge-case error when changing the version of Remix and then making a deployment to Vercel when there is already an existing build cache:
> Error: EEXIST: file already exists, symlink '../.pnpm/@remix-run+server-runtime@1.5.0_biqbaboplfbrettd7655fr4n2y/node_modules/@remix-run/server-runtime' -> '/vercel/path0/node_modules/@remix-run/server-runtime'
This would happen because the symlink was created in a previous run, but no longer points to a valid path because it's a different version. To fix we'll delete the previous symlink when the target value does not match.
Adds support for bundling properly the dependencies used by the experimental instrumentation hook file, `instrumentation.js`, by adding the generated nft file to the list of server deps
fixes NEXT-631
There's [a PR](https://github.com/remix-run/remix/pull/5537) opened on
Remix to add an Edge compatible entrypoint to `@remix-run/vercel`. This
is only really needed specifically for projects that have a custom
server.js entrypoint file, which is not strictly necessary anymore, but
there are some edge cases where a project might still want to have one.
So this PR is necessary for those kinds of projects to be able to use
Edge runtime.
Even when they merge the PR, it would be good to leave this injection
code around for some time to continue support for older
`@remix-run/vercel` versions in existing projects.
Updates the `responseHeaders` probe checks to properly test for multiple headers with the same name.
Previously the probes were using `headers.get()` which concats multiple headers into a single string, which results in the test not really checking if there are in fact multiple headers with the same name. Using `headers.raw()` allows us to properly test for that.
A couple of Python tests that were already checking for multiple `set-cookie` headers needed to be updated to match the full value, since the check now properly validates the full string match of each header (before it was basically just doing a `string.includes()` check).
This is a precursor for https://github.com/vercel/vercel/pull/9533.
If for some reason the `get-latest-worker.js` fails to get the dist-tags, it doesn't check the status code and proceeds to `JSON.parse()` the response. If for example npm returns 401 Unauthorized, you get a cryptic JSON parse error message.
Fixes this error:
```
@vercel/node:test-unit: FAIL test/dev.test.ts (14.891 s)
@vercel/node:test-unit: × runs a mjs endpoint (5057 ms)
@vercel/node:test-unit: × runs a esm typescript endpoint (5122 ms)
@vercel/node:test-unit:
@vercel/node:test-unit: ● runs a mjs endpoint
@vercel/node:test-unit:
@vercel/node:test-unit: thrown: "Exceeded timeout of 5000 ms for a test.
@vercel/node:test-unit: Use jest.setTimeout(newTimeout) to increase the timeout value, if this is a long-running test."
```
https://github.com/vercel/vercel/actions/runs/4247588973/jobs/7385801227#step:9:1039
In a Turborepo setup, there was this in the `remix.config.js` file:
```js
watchPaths: [require.resolve("ui")],
```
Since we attempt to `require()` the `remix.config.js` file in order to
determine whether or not it is using ESM syntax, this would fail since
the require happens before the Build Command is executed.
To fix, treat any non `ERR_REQUIRE_ESM` error as CJS, instead of
re-throwing the error. If there really is an issue with importing the
config, then that'll happen right after when `remix build` is doing it.
When the project defines a custom `server.js` file in `remix.config.js`,
then don't override that with the bundled
`server-node.mjs`/`server-edge.mjs` file. This allows for a custom
`getLoadContext()` function to remain supported.
In order for Edge runtime to be supported, a [companion
PR](https://github.com/remix-run/remix/pull/5537) for
`@remix-run/vercel` adapter has been created with a dedicated entrypoint
for when Edge runtime is being used. In order to support Edge on
previous versions of the adapter, we may end up patching the package to
enable support, but that will happen in a follow-up PR.
Related to https://github.com/orgs/vercel/discussions/1596.
---------
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
Make it so that the `export const config = { runtime }` value is "inherited" from a parent route, if it is defined.
For example, "edge" can be defined in `app/root.tsx`, and so all routes will use the Edge runtime by default, unless `"runtime": "nodejs"` is used more specifically in a route deeper in the route hierarchy.
`vc remove --safe <project>` has a unique code path that queries all deployments by project id. This function calls v4 deployments endpoint and returns the legacy deployment structure.
The problem is the `vc remove` command relies on the new `Deployment` structure defined by the v13 get deployment endpoint.
I've updated the `getDeploymentsByProjectId()` function to transform the legacy structure into the current one.
Fixes#9321
Linear: https://linear.app/vercel/issue/VCCLI-538/vc-rm-project-safe-is-not-working
After many hours of debugging, I tracked down that having an old Node
version (eg 14.x) listed in your Vercel project settings can result in
the build step failing with a confusing and unhelpful error message
"`@vercel/next` No Serverless Pages Built". Note that this is a case
where it "can" cause it to fail, including with NextJS 13.1.6 and Vercel
CLI 28.16.2, but it is not guaranteed to fail. I have six NextJS
projects. They have identical next.config.js, tsconfig.json,
eslintrc.js, and .gitignore files, and other than a few seemingly
non-critical dependencies they have identical package.json files. Four
of the six consistently built and deployed in the cloud without issue.
Two consistently failed to build in the cloud. All built successfully
locally including using vercel build locally, and all would vercel
deploy --prebuilt successfully. Switching all the vercel cloud project
settings from Node 14.x to Node 18.x enabled all the projects to build
and deploy successfully in the vercel cloud without needing local vercel
build and local vercel deploy --prebuilt steps.
---------
Co-authored-by: Steven <steven@ceriously.com>
This PR changes the fallback headers that relate to RSC to the defaults that Next.js currently uses. Also, it sets the initial `vary` header to all prerendered routes when RSC is enabled (`routesManifest?.rsc`), even for the pages directory.
That's because although the pages directory won't return any RSC payload, it can still be used in a project that contains app routes. When the app route requests a page route for RSC data, it's important for the browser to not accidentally cache that result hence we need the `vary` header to set there as well.
More related discussions can be found [here](https://linear.app/vercel/issue/NEXT-382/add-vary-rsc-etc-header-to-all-responses-to-ensure-browser-caching).
In order to have Next.js Lambdas show their operation types more specifically in the build output in the dashboard, the builder needs to return the Lambdas with `operationType` set to the appropriate value.
This PR adds those values. This allows the Richer Deployment Outputs to show the different types of serverless functions:
<img width="228" alt="Screenshot 2023-02-03 at 3 49 42 PM" src="https://user-images.githubusercontent.com/41545/216717479-d02fbd4a-fa62-479d-8b65-bd77fdcdb26c.png">
Missed this occurrence so it still prevents the upload of serverless
functions that have a mem value that is not dividable by 64.
Should be the last place before we can ship the documentation update.
#### Related PRs
- #9440
Co-authored-by: Steven <steven@ceriously.com>
When WEBrick receives `HEAD` requests it discards the body (i.e.
`req.body.nil? => true`), this causes Vercel to throw a
`BODY_NOT_A_STRING_FROM_FUNCTION` since it is expecting the serverless
function to respond with a string in the body.
---------
Co-authored-by: Nathan Rajlich <n@n8.io>
Co-authored-by: Steven <steven@ceriously.com>
This PR changes the way cron jobs are being created in the build output
API. This is my first time contributing here. If you see something
unusual, let me know.
✅ Good for review
Our goal is to:
- Allow creating cron jobs via the `crons` property of `vercel.json` for
end users
- Allow framework authors to create cron jobs on Vercel via the `crons`
property of the Build Output API configuration
---
As you can see, we removed the previous implementation where cron jobs
could be configured at the function code level (export const cron = ""),
on top of vercel.json `functions` property. Here's why:
- All frameworks would have to implement the configure at the function
code level
- Not all frameworks can easily map a path to a specific function
(example: SvelteKit) and would have to bail on bundling functions inside
the same lambda
- Configuring a path + scheduler provides a better mapping of what cron
jobs are as of today: API routes on a schedule and not functions on a
schedule
- Dynamic routes Cron Jobs will be supported:
/api/crons/sync-slack-team/230
- Query parameters will be supported support:
/api/crons/sync-slack-team/230?secret=32k13l2k13lk21 (= securing cron
jobs v0)
- 100% frameworks compatibility from day one
Next.js and other frameworks may choose to implement their own cron jobs
feature that will then need to be configured through the `crons`
property of `config.json` (build output API).
cc @timneutkens @Rich-Harris
Internal thread:
https://vercel.slack.com/archives/C04DWF5HB6K/p1676366892714349
Adds framework to Lambda and edge build outputs so that we can distinguish which framework they originated from when certain features should be applied to specific frameworks.
This PR adds framework to the outputs. Part 1: https://github.com/vercel/vercel/pull/9448
ticket: ED-131
x-ref: [slack channel](https://vercel.slack.com/archives/C042LHPJ1NX)
`spawnSync()` does not throw if the command can't be found in the PATH or if an error occurs. If we use `execFileSync()`, it will throw and that was likely the desired behavior in this test utility function.
This adds a new package to the monorepo: `@vercel/remix-entry-server`
The purpose of this package is to provide most of the implementation of
the Remix `app/entry.server.tsx` file with proper support for the Vercel
Serverless and Edge runtimes, specifically in regards to React 18
streaming.
The reason that this package is necessary, as opposed to just updating
our Remix template, is due to the fact that Serverless and Edge runtimes
require a different implementation. This is because the
`react-dom/server` package exports different functions for the Node
(`renderToPipeableStream()`) vs. Edge (`renderToReadableStream()`)
bundles, and thus this package also has two different implementations
(by utilizing the `main` and `browser` fields in `package.json`).
Usage of this package in a Remix application's `app/entry.server.tsx`
file looks like:
```tsx
import handleRequest from "@vercel/remix-entry-server";
import { RemixServer } from "@remix-run/react";
import type { EntryContext } from "@remix-run/server-runtime";
export default function (
request: Request,
responseStatusCode: number,
responseHeaders: Headers,
remixContext: EntryContext
) {
const remixServer = <RemixServer context={remixContext} url={request.url} />;
return handleRequest(request, responseStatusCode, responseHeaders, remixServer)
}
```
Once this package is published then we can update our own Remix template
to utilize it, enabling React 18 streaming for both Vercel runtimes.
We no longer require the memory to be provided in steps of 64mb for
serverless functions.
Instead the memory can now be chosen freely from `128mb` to `3008mb` in
`1mb increments`.
Updates the `vercel.json` schema to reflect that change.
Adds support for server-side rendered Remix using Edge Functions. This runtime can be enabled on a per-page basis, by adding the following to a page within the `app/routes` directory:
```js
export const config = {
runtime: 'edge'
};
```
Additionally, this PR further supersedes the `@remix-run/vercel` runtime adapter, because we will always inject our own server entrypoint. So the logic to ensure that package exists in the project's `package.json` has been removed (so this closes#9011). The only requirement is that the Remix project has `@remix-run/node` as a dependency, which is the case for the vanilla Remix template so I think that's a fair assumption.
To make Edge Functions work, we need to ensure that `remix build` is executed with a few specific configuration values in place, so this change wraps the existing `remix.config.js` file and adds our own to make sure those values are in place (and then cleans itself up after the build command is executed).
Finally, the reading of the Remix config logic was simplified by using the `readConfig()` function from the `@remix-run/dev` package, which also includes the routes manifest, so the hacky `vm` running logic to retrieve the manifest was able to be removed.
Closes#8784.
Closes#9011.
---
# To test this out:
1. Ensure that Remix dependencies are running _at least version `1.5.0`_ (which is when `writeReadableStreamToWritable()` was added to `@remix-run/node`).
2. Add the following line of code to any page in your Remix application’s `app/routes/*` directory:
```jsx
export const config = { runtime: 'edge' };
```
3. Set an Environment Variable on your Vercel Project:
- Name: `VERCEL_CLI_VERSION`
- Value: `https://vercel-git-update-remix-edge.vercel.sh/tarballs/vercel.tgz`
4. Make a deployment, either by running `vercel deploy` in the CLI, or by pushing a Git commit to your repository which has a Vercel Git integration enabled.
In an effort to speed up CI, we should update the lowest common
denominator to Node.js 16
Note: In April, Node.js 14 will reach EOL so we can update tsconfig
targets and ship a major semver at that time.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This makes `react-dom` work as expected from within Edge Functions. Otherwise, NFT will only select the Node.js version of the files which do not work with react-dom within an Edge Function.
The error messages shown during `vc dev` when an Edge or Serverless functions returns a promise that ends up being rejected could be better.
Main changes:
- removed "socket hang up" error messages because they were not helpful to the user
- changed serverless function error handling to log explicitly and exit
- changed serverless function error message to include the request path
- changed edge function error message to include request path and a faked (but useful) stack trace
## Current
### In Production
**Serverless Function:** In production, for a serverless function rejected promise, you'll see this in the logs:
```
Unhandled Promise Rejection {
"errorType": "Runtime.UnhandledPromiseRejection",
"errorMessage": "Error: intentional break!",
"reason": {
"errorType": "Error",
"errorMessage": "intentional break!",
"stack": [
"Error: intentional break!",
" at handler (/var/task/api/node.js:3:9)",
" at Server.<anonymous> (/var/task/___vc/__helpers.js:813:19)",
" at Server.emit (node:events:527:28)",
" at parserOnIncoming (node:_http_server:956:12)",
" at HTTPParser.parserOnHeadersComplete (node:_http_common:128:17)"
]
},
"promise": {},
"stack": [
"Runtime.UnhandledPromiseRejection: Error: intentional break!",
" at process.<anonymous> (file:///var/runtime/index.mjs:1194:17)",
" at process.emit (node:events:539:35)",
" at process.emit (/var/task/___vc/__sourcemap_support.js:559:21)",
" at emit (node:internal/process/promises:140:20)",
" at processPromiseRejections (node:internal/process/promises:274:27)",
" at processTicksAndRejections (node:internal/process/task_queues:97:32)"
]
}
Unknown application error occurred
Runtime.Unknown
```
**Edge Function:** In production, for an edge function rejected promise, you'll see this in the logs:
```
Error: intentional break!
at (api/edge.js:10:10)
```
In both cases, in the browser, you see the "This Serverless/Edge Function has crashed." template with no error message or stack trace.
### In `vc dev`
**Serverless Function:** In `vc dev`, for a serverless function rejected promise, you'll see this in the output:
```
Unhandled rejection: Error: intentional break!
at handler (/Users/smassa/source/demo/edge-errors/api/node.js:3:9)
at Server.<anonymous> (/Users/smassa/source/vercel/vercel/packages/node-bridge/helpers.js:813:19)
at Server.emit (node:events:513:28)
at Server.emit (node:domain:489:12)
at parserOnIncoming (node:_http_server:998:12)
at HTTPParser.parserOnHeadersComplete (node:_http_common:128:17)
Error: Failed to complete request to /api/node: Error: socket hang up
```
**Edge Function:** In `vc dev`, for an edge function rejected promise, you'll see this in the output:
```
Unhandled rejection: intentional break!
Error: Failed to complete request to /api/edge: Error: socket hang up
```
## After Changes
### In `vc dev`
**Serverless Function:** In `vc dev`, for a serverless function rejected promise, you'll see this in the output:
```
Rejected Promise returned from /api/node: Error: intentional break!
at handler (/Users/smassa/source/demo/edge-errors/api/node.js:3:9)
at Server.<anonymous> (/Users/smassa/source/vercel/vercel/packages/node-bridge/helpers.js:824:19)
at Server.emit (node:events:513:28)
at Server.emit (node:domain:489:12)
at parserOnIncoming (node:_http_server:998:12)
at HTTPParser.parserOnHeadersComplete (node:_http_common:128:17)
```
**Edge Function:** In `vc dev`, for an edge function rejected promise, you'll see this in the output:
```
Rejected Promise returned from api/edge: intentional break!
at (api/edge.ts)
```
We can't show the real stack trace for Edge Functions because the bundling + VM execution mangles it. What's rendered here is a fake one, but it's still useful to the user.
If we currently showed the real stack trace for edge functions, it would look like:
```
Rejected Promise returned from api/edge: intentional break!
at edge (evalmachine.<anonymous>:35:9)
at FetchEvent.<anonymous> (evalmachine.<anonymous>:87:26)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async EdgeRuntime.dispatchFetch (evalmachine.<anonymous>:29:7)
at async Server.handler (/Users/smassa/source/vercel/vercel/node_modules/.pnpm/edge-runtime@2.0.0/node_modules/edge-runtime/src/server/create-handler.ts:46:26)
```
## Follow Up
We'll look into improving the Edge Function error stack traces later.
These tests will run if one of the conditions is met:
- any change to `./examples`
- any changes to `./packages/frameworks`
The test ensures that examples can build and deploy without errors.
In a future PR, we could improve these tests to make requests to the
test deployment (like we do for probes).
Since turbo and nx only consider `NEXT_PUBLIC_` prefixed env variables for the cache key this ensures we expose variables that affect the build in that format as well so that an incompatible build cache isn't attempted to be leveraged. No additional tests were added here as this related to build cache which can't be reliably tested here.
x-ref: [slack thread](https://vercel.slack.com/archives/C03S8ED1DKM/p1675821643786319)
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
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.
## Local development
This project is configured in a monorepo, where one repository contains multiple npm packages. Dependencies are installed and managed with `yarn`, 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-unit
```
Make sure all the tests pass before making changes.
## 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:
```
yarn test-unit
```
from the root of the project.
If any test fails, make sure to fix it along with your changes. See [Interpreting test errors](#Interpreting-test-errors) for more information about how the tests are executed, especially the integration tests.
## Pull Request Process
Once you are confident that your changes work properly, open a pull request on the main repository.
The pull request will be reviewed by the maintainers and the tests will be checked by our continuous integration platform.
## Interpreting test errors
There are 2 kinds of tests in this repository – Unit tests and Integration tests.
Unit tests are run locally with `jest` and execute quickly because they are testing the smallest units of code.
### Integration tests
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.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
connection=close
content-type=text/plain; charset=utf-8
date=Wed, 19 Jun 2019 18:01:37 GMT
server=now
strict-transport-security=max-age=63072000
transfer-encoding=chunked
x-now-id=iad1:hgtzj-1560967297876-44ae12559f95
x-now-trace=iad1]
```
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.
### @vercel/nft
Some of the Builders use `@vercel/nft` to tree-shake files before deployment. If you suspect an error with this tree-shaking mechanism, you can create the following script in your project:
```js
const{nodeFileTrace}=require('@vercel/nft');
nodeFileTrace(['path/to/entrypoint.js'],{
ts:true,
mixedModules:true,
})
.then(o=>console.log(o.fileList))
.then(e=>console.error(e));
```
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 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
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
6. Run `vercel` or `vercel dev` to deploy with the experimental Builder
See the [Contributing Guidelines](../README.md#contributing) for more details.
**Note**: This category is intended for discussions related to Vercel CLI or Runtimes.
If you post in this repository seeking help with other Vercel tools and features, it may be missed by our support team. For help with topics other than the CLI and Runtimes, please visit the [Vercel Community](https://github.com/orgs/vercel/discussions).
**Note**: This category is intended for discussions related to Vercel CLI or Runtimes.
If you post in this repository seeking help with other Vercel tools and features, it may be missed by our support team. For help with topics other than the CLI and Runtimes, please visit the [Vercel Community](https://github.com/orgs/vercel/discussions).
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:
@@ -26,7 +28,7 @@ Official Runtimes are published to [the npm registry](https://npmjs.com) as a pa
> **Note:** The `use` property in the `builds` array will work with any [npm
> install argument](https://docs.npmjs.com/cli/install) such as a git repo URL,
> which is useful for testing your Runtime. Alternatively, the `functions` property
> requires that you specify a specifc tag published to npm, for stability purposes.
> requires that you specify a specific tag published to npm, for stability purposes.
See the [Runtimes Documentation](https://vercel.com/docs/runtimes) to view example usage.
@@ -61,9 +63,6 @@ export async function build(options: BuildOptions) {
constlambda=createLambda(/* … */);
return{
output: lambda,
watch:[
// Dependent files to trigger a rebuild in `vercel dev` go here…
],
routes:[
// If your Runtime needs to define additional routing, define it here…
],
@@ -80,18 +79,23 @@ project. An example use-case is that `@vercel/node` uses this function to cache
the `node_modules` directory, making it faster to install npm dependencies for
future builds.
> Note: Only files within the repo root directory can be cached.
@@ -113,7 +117,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
@@ -187,7 +192,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`.
@@ -195,6 +201,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`.
@@ -302,20 +379,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:
Vercel is a platform for **static sites and frontend frameworks**, built to integrate with your headless content, commerce, or database.
We provide a **frictionless developer experience** to take care of the hard things: deploy instantly, scale automatically, and serve personalized content around the globe.
We make it easy for frontend teams to **develop, preview, and ship** delightful user experiences, where performance is the default.
Vercel’s Frontend Cloud provides the developer experience and infrastructure to build, scale, and secure a faster, more personalized Web.
## 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.
Get started by [importing a project](https://vercel.com/new) or using the [Vercel CLI](https://vercel.com/docs/cli). Then, `git push` to deploy.
## Documentation
@@ -35,6 +31,141 @@ For details on how to use Vercel, check out our [documentation](https://vercel.c
## Contributing
- [Code of Conduct](https://github.com/vercel/vercel/blob/main/.github/CODE_OF_CONDUCT.md)
This project uses [pnpm](https://pnpm.io/) to install dependencies and run scripts.
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`.
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](./.github/CODE_OF_CONDUCT.md) and follow it in all your interactions with the project.
### Local development
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
cd vercel
corepack enable
pnpm install
pnpm build
pnpm lint
pnpm test-unit
```
Make sure all the tests pass before making changes.
#### Running Vercel CLI Changes
You can use `pnpm dev` from the `cli` package to invoke Vercel CLI with local changes:
```
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.
If any test fails, make sure to fix it along with your changes. See [Interpreting test errors](#Interpreting-test-errors) for more information about how the tests are executed, especially the integration tests.
### Pull Request Process
Once you are confident that your changes work properly, open a pull request on the main repository.
The pull request will be reviewed by the maintainers and the tests will be checked by our continuous integration platform.
### Interpreting test errors
There are 2 kinds of tests in this repository – Unit tests and Integration tests.
Unit tests are run locally with `jest` and execute quickly because they are testing the smallest units of code.
#### Integration tests
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.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
connection=close
content-type=text/plain; charset=utf-8
date=Wed, 19 Jun 2019 18:01:37 GMT
server=now
strict-transport-security=max-age=63072000
transfer-encoding=chunked
x-now-id=iad1:hgtzj-1560967297876-44ae12559f95
x-now-trace=iad1]
```
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.
##### Running integration tests locally
While running the full integration suite locally is not recommended, it's sometimes useful to isolate a failing test by running it on your machine. To do so, you'll need to ensure you have the appropriate credentials sourced in your shell:
1. Create an access token. Follow the insructions here https://vercel.com/docs/rest-api#creating-an-access-token. Ensure the token scope is for your personal
account.
2. Grab the team ID from the Vercel dashboard at `https://vercel.com/<MY-TEAM>/~/settings`.
3. Source these into your shell rc file: `echo 'export VERCEL_TOKEN=<MY-TOKEN> VERCEL_TEAM_ID=<MY-TEAM-ID>' >> ~/.zshrc`
From there, you should be able to trigger an integration test. Choose one
that's already isolated to check that things work:
```
cd packages/next
```
Run the test:
```
pnpm test test/fixtures/00-server-build/index.test.js
```
#### @vercel/nft
Some of the Builders use `@vercel/nft` to tree-shake files before deployment. If you suspect an error with this tree-shaking mechanism, you can create the following script in your project:
```js
const{nodeFileTrace}=require('@vercel/nft');
nodeFileTrace(['path/to/entrypoint.js'],{
ts:true,
mixedModules:true,
})
.then(o=>console.log(o.fileList))
.then(e=>console.error(e));
```
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 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 `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
6. Run `vercel` or `vercel dev` to deploy with the experimental Builder
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/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`.
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.local`.
We require this to ensure your app works as you intend it to, in the development environment, and to provide you with a way to mirror or separate private environment variables within your applications, for example when connecting to a database.
@@ -12,11 +12,11 @@ Read below for how to address this error.
#### Possible Ways to Fix It
The error message will list environment variables that are required and which file they are required to be included in `.env`.
The error message will list environment variables that are required and which file they are required to be included in `.env.local`.
If the file does not exist yet, please create the file that the error message mentions and insert the missing environment variable into it.
For example, if the error message shows that the environment variable `TEST` is missing from `.env`, then the `.env` file should look like this:
For example, if the error message shows that the environment variable `TEST` is missing from `.env.local`, then the `.env.local` file should look like this:
`@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)
@@ -14,7 +14,9 @@ In order to create the smallest possible lambdas Next.js has to be configured to
npm install next --save
```
2.Add the `now-build` script to your `package.json`
2.Check [Node.js Version](https://vercel.link/node-version) in your Project Settings. Using an old or incompatible version of Node.js can cause the Build Step to fail with this error message.
3. Add the `now-build` script to your `package.json` [deprecated]
```json
{
@@ -24,7 +26,7 @@ npm install next --save
}
```
3. Add `target: 'serverless'` to `next.config.js`
4. Add `target: 'serverless'` to `next.config.js` [deprecated]
```js
module.exports={
@@ -33,13 +35,15 @@ module.exports = {
};
```
4. Remove `distDir` from `next.config.js` as `@now/next` can't parse this file and expects your build output at `/.next`
5. Remove `distDir` from `next.config.js` as `@vercel/next` can't parse this file and expects your build output at `/.next`
5. Optionally make sure the `"src"` in `"builds"` points to your application `package.json`
6. Optionally make sure the `"src"` in `"builds"` points to your application `package.json`
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 could be caused by a misconfigured "Build Command" or "Output Directory" for your Next.js project.
This error is often caused by a misconfigured "Build Command" or "Output Directory" for your Next.js project.
#### Possible Ways to Fix It
In the Vercel dashboard, open your "Project Settings" and draw attention to "Build & Development Settings":
1. Ensure that the "Build Command" setting is not changed, or that it calls `next build`. If this command is not changed but you are seeing this error, double check that your `build` script in `package.json` calls `next build`.
2. Ensure that the "Output Directory" setting is not changed. This value almost never needs to be configured, and is only necessary if you override `distDir` in `next.config.js`.
3. For `next export` users: **do not override the "Output Directory"**. Next.js automatically detects what folder you outputted `next export` to.
1. Ensure that the "Build Command" setting is not overridden, or that it calls `next build`. If this command is not overridden but you are seeing this error, double check that your `build` script in `package.json` calls `next build`. If `buildCommand` exists in `vercel.json`, make sure it calls `next build`.
2. Ensure that the "Output Directory" setting is not overridden. This value almost never needs to be configured, and is only necessary if you override `distDir` in `next.config.js`. If `outputDirectory` exists in `vercel.json`, remove that property.
3. For `next export` users: **do not override the "Output Directory"**, even if you customized the `next export` output directory. It will automatically detects the correct output.
In rare scenarios, this error message can also be caused by a Next.js build failure (if your "Build Command" accidentally returns an exit code that is not 0).
Double check for any error messages above the Routes Manifest error, which may provide additional details.
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:
To get started using any of these examples as your own project, [install Vercel](https://vercel.com/docs/cli) and use either of the following commands in your terminal:
it('[examples] should deploy vitepress',async()=>{
awaitdeployExample('vitepress');
});
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.
