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.
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.
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 | });
```
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
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)
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.
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.
`.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 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.
* 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
