rsnext/packages/next/server/dev/static-paths-worker.ts

93 lines
2.2 KiB
TypeScript
Raw Normal View History

import type { NextConfigComplete } from '../config-shared'
import '../node-polyfill-fetch'
import {
buildAppStaticPaths,
buildStaticPaths,
collectGenerateParams,
} from '../../build/utils'
import { loadComponents } from '../load-components'
feat(experimental): option to polyfill `fetch` using `undici` in Node.js <18 (#40318) This PR adds a new `experimental.enableUndici` option to let the developer switch from `next-fetch` to `undici` as the underlying polyfill for `fetch` in Node.js. In the current implementation, Next.js makes sure that `fetch` is always available by using `node-fetch`. However, we do not polyfill in Node.js 18+, since those versions come with their own `fetch` implementation already, built-in. Node.js 18+ uses `undici` under the hood, so letting the developer use `undici` earlier could make the migration easier later on. Eventually, we hope to be able to stop polyfilling `fetch` in an upcoming major version of Next.js, shipping less code. ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` ## Feature - [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [ ] Errors have helpful link attached, see `contributing.md` ## Documentation / Examples - [ ] Make sure the linting passes by running `pnpm lint` - [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples) Co-authored-by: Balázs Orbán <info@balazsorban.com> Co-authored-by: Sukka <isukkaw@gmail.com> Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Steven <steven@ceriously.com>
2022-09-27 22:37:28 +02:00
import { setHttpClientAndAgentOptions } from '../config'
type RuntimeConfig = any
let workerWasUsed = false
// we call getStaticPaths in a separate process to ensure
// side-effects aren't relied on in dev that will break
// during a production build
export async function loadStaticPaths({
distDir,
pathname,
serverless,
config,
httpAgentOptions,
feat(experimental): option to polyfill `fetch` using `undici` in Node.js <18 (#40318) This PR adds a new `experimental.enableUndici` option to let the developer switch from `next-fetch` to `undici` as the underlying polyfill for `fetch` in Node.js. In the current implementation, Next.js makes sure that `fetch` is always available by using `node-fetch`. However, we do not polyfill in Node.js 18+, since those versions come with their own `fetch` implementation already, built-in. Node.js 18+ uses `undici` under the hood, so letting the developer use `undici` earlier could make the migration easier later on. Eventually, we hope to be able to stop polyfilling `fetch` in an upcoming major version of Next.js, shipping less code. ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` ## Feature - [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [ ] Errors have helpful link attached, see `contributing.md` ## Documentation / Examples - [ ] Make sure the linting passes by running `pnpm lint` - [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples) Co-authored-by: Balázs Orbán <info@balazsorban.com> Co-authored-by: Sukka <isukkaw@gmail.com> Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Steven <steven@ceriously.com>
2022-09-27 22:37:28 +02:00
enableUndici,
locales,
defaultLocale,
isAppPath,
originalAppPath,
}: {
distDir: string
pathname: string
serverless: boolean
config: RuntimeConfig
httpAgentOptions: NextConfigComplete['httpAgentOptions']
feat(experimental): option to polyfill `fetch` using `undici` in Node.js <18 (#40318) This PR adds a new `experimental.enableUndici` option to let the developer switch from `next-fetch` to `undici` as the underlying polyfill for `fetch` in Node.js. In the current implementation, Next.js makes sure that `fetch` is always available by using `node-fetch`. However, we do not polyfill in Node.js 18+, since those versions come with their own `fetch` implementation already, built-in. Node.js 18+ uses `undici` under the hood, so letting the developer use `undici` earlier could make the migration easier later on. Eventually, we hope to be able to stop polyfilling `fetch` in an upcoming major version of Next.js, shipping less code. ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` ## Feature - [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [ ] Errors have helpful link attached, see `contributing.md` ## Documentation / Examples - [ ] Make sure the linting passes by running `pnpm lint` - [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples) Co-authored-by: Balázs Orbán <info@balazsorban.com> Co-authored-by: Sukka <isukkaw@gmail.com> Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Steven <steven@ceriously.com>
2022-09-27 22:37:28 +02:00
enableUndici: NextConfigComplete['enableUndici']
locales?: string[]
defaultLocale?: string
isAppPath?: boolean
originalAppPath?: string
}): Promise<{
paths?: string[]
encodedPaths?: string[]
fallback?: boolean | 'blocking'
}> {
// we only want to use each worker once to prevent any invalid
// caches
if (workerWasUsed) {
process.exit(1)
}
// update work memory runtime-config
require('../../shared/lib/runtime-config').setConfig(config)
feat(experimental): option to polyfill `fetch` using `undici` in Node.js <18 (#40318) This PR adds a new `experimental.enableUndici` option to let the developer switch from `next-fetch` to `undici` as the underlying polyfill for `fetch` in Node.js. In the current implementation, Next.js makes sure that `fetch` is always available by using `node-fetch`. However, we do not polyfill in Node.js 18+, since those versions come with their own `fetch` implementation already, built-in. Node.js 18+ uses `undici` under the hood, so letting the developer use `undici` earlier could make the migration easier later on. Eventually, we hope to be able to stop polyfilling `fetch` in an upcoming major version of Next.js, shipping less code. ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` ## Feature - [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [ ] Errors have helpful link attached, see `contributing.md` ## Documentation / Examples - [ ] Make sure the linting passes by running `pnpm lint` - [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples) Co-authored-by: Balázs Orbán <info@balazsorban.com> Co-authored-by: Sukka <isukkaw@gmail.com> Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Steven <steven@ceriously.com>
2022-09-27 22:37:28 +02:00
setHttpClientAndAgentOptions({
httpAgentOptions,
experimental: { enableUndici },
})
Subresource Integrity for App Directory (#39729) <!-- Thanks for opening a PR! Your contribution is much appreciated. In order 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 serves to add support for [Subresource Integrity](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) hashes for scripts added from the new app directory. This also has support for utilizing nonce values passed from request headers (expected to be generated per request in middleware) in the bootstrapping scripts via the `Content-Security-Policy` header as such: ``` Content-Security-Policy: script-src 'nonce-2726c7f26c' ``` Which results in the inline scripts having a new `nonce` attribute hash added. These features combined support for setting an aggressive Content Security Policy on scripts loaded. ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` ## Feature - [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [x] Errors have helpful link attached, see `contributing.md` ## Documentation / Examples - [x] Make sure the linting passes by running `pnpm lint` - [x] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples) Co-authored-by: Steven <steven@ceriously.com>
2022-09-09 00:17:15 +02:00
const components = await loadComponents({
distDir,
pathname: originalAppPath || pathname,
serverless,
Subresource Integrity for App Directory (#39729) <!-- Thanks for opening a PR! Your contribution is much appreciated. In order 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 serves to add support for [Subresource Integrity](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) hashes for scripts added from the new app directory. This also has support for utilizing nonce values passed from request headers (expected to be generated per request in middleware) in the bootstrapping scripts via the `Content-Security-Policy` header as such: ``` Content-Security-Policy: script-src 'nonce-2726c7f26c' ``` Which results in the inline scripts having a new `nonce` attribute hash added. These features combined support for setting an aggressive Content Security Policy on scripts loaded. ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` ## Feature - [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [x] Errors have helpful link attached, see `contributing.md` ## Documentation / Examples - [x] Make sure the linting passes by running `pnpm lint` - [x] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples) Co-authored-by: Steven <steven@ceriously.com>
2022-09-09 00:17:15 +02:00
hasServerComponents: false,
isAppPath: !!isAppPath,
Subresource Integrity for App Directory (#39729) <!-- Thanks for opening a PR! Your contribution is much appreciated. In order 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 serves to add support for [Subresource Integrity](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) hashes for scripts added from the new app directory. This also has support for utilizing nonce values passed from request headers (expected to be generated per request in middleware) in the bootstrapping scripts via the `Content-Security-Policy` header as such: ``` Content-Security-Policy: script-src 'nonce-2726c7f26c' ``` Which results in the inline scripts having a new `nonce` attribute hash added. These features combined support for setting an aggressive Content Security Policy on scripts loaded. ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` ## Feature - [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [x] Errors have helpful link attached, see `contributing.md` ## Documentation / Examples - [x] Make sure the linting passes by running `pnpm lint` - [x] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples) Co-authored-by: Steven <steven@ceriously.com>
2022-09-09 00:17:15 +02:00
})
if (!components.getStaticPaths && !isAppPath) {
// we shouldn't get to this point since the worker should
// only be called for SSG pages with getStaticPaths
throw new Error(
`Invariant: failed to load page with getStaticPaths for ${pathname}`
)
}
workerWasUsed = true
if (isAppPath) {
const generateParams = collectGenerateParams(components.ComponentMod.tree)
return buildAppStaticPaths({
page: pathname,
generateParams,
configFileName: config.configFileName,
})
}
return buildStaticPaths({
page: pathname,
getStaticPaths: components.getStaticPaths,
configFileName: config.configFileName,
locales,
defaultLocale,
})
}