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 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.
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>
