rsnext/packages/next/taskfile.js

2876 lines
88 KiB
JavaScript
Raw Normal View History

const { relative, basename, resolve, join, dirname } = require('path')
// eslint-disable-next-line import/no-extraneous-dependencies
const glob = require('glob')
// eslint-disable-next-line import/no-extraneous-dependencies
const fs = require('fs/promises')
// eslint-disable-next-line import/no-extraneous-dependencies
const resolveFrom = require('resolve-from')
const execa = require('execa')
2020-03-29 18:56:34 +02:00
export async function next__polyfill_nomodule(task, opts) {
await task
.source(relative(__dirname, require.resolve('@next/polyfill-nomodule')))
2020-03-29 18:56:34 +02:00
.target('dist/build/polyfills')
}
export async function next__polyfill_module(task, opts) {
await task
.source(relative(__dirname, require.resolve('@next/polyfill-module')))
.target('dist/build/polyfills')
}
export async function browser_polyfills(task, opts) {
await task.parallel(
['next__polyfill_nomodule', 'next__polyfill_module'],
opts
)
}
// eslint-disable-next-line camelcase
export async function copy_regenerator_runtime(task, opts) {
await task
.source(join(dirname(require.resolve('regenerator-runtime')), '**/*'))
.target('src/compiled/regenerator-runtime')
2020-03-29 18:56:34 +02:00
}
// eslint-disable-next-line camelcase
export async function copy_styled_jsx_assets(task, opts) {
// we copy the styled-jsx types so that we can reference them
// in the next-env.d.ts file so it doesn't matter if the styled-jsx
// package is hoisted out of Next.js' node_modules or not
const styledJsxPath = dirname(require.resolve('styled-jsx/package.json'))
const typeFiles = glob.sync('*.d.ts', { cwd: styledJsxPath })
const outputDir = join(__dirname, 'dist/styled-jsx')
// Separate type files into different folders to avoid conflicts between
// dev dep `styled-jsx` and `next/dist/styled-jsx` for duplicated declare modules
const typesDir = join(outputDir, 'types')
await fs.mkdir(typesDir, { recursive: true })
for (const file of typeFiles) {
const content = await fs.readFile(join(styledJsxPath, file), 'utf8')
await fs.writeFile(join(typesDir, file), content)
}
}
2020-03-29 18:16:32 +02:00
const externals = {
// don't bundle caniuse-lite data so users can
// update it manually
'caniuse-lite': 'caniuse-lite',
'/caniuse-lite(/.*)/': 'caniuse-lite$1',
2020-03-30 03:25:10 +02:00
'node-fetch': 'node-fetch',
postcss: 'postcss',
// Ensure latest version is used
'postcss-safe-parser': 'next/dist/compiled/postcss-safe-parser',
// sass-loader
// (also responsible for these dependencies in package.json)
'node-sass': 'node-sass',
sass: 'sass',
fibers: 'fibers',
2020-03-30 03:25:10 +02:00
chokidar: 'chokidar',
'jest-worker': 'jest-worker',
2021-09-21 16:22:57 +02:00
'terser-webpack-plugin':
'next/dist/build/webpack/plugins/terser-webpack-plugin',
// TODO: Add @swc/helpers to externals once @vercel/ncc switch to swc-loader
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
undici: 'undici',
2020-03-29 05:41:35 +02:00
}
// eslint-disable-next-line camelcase
externals['node-html-parser'] = 'next/dist/compiled/node-html-parser'
export async function ncc_node_html_parser(task, opts) {
await task
.source(relative(__dirname, require.resolve('node-html-parser')))
.ncc({
packageName: 'node-html-parser',
externals,
target: 'es5',
})
.target('src/compiled/node-html-parser')
}
// eslint-disable-next-line camelcase
externals['@mswjs/interceptors/ClientRequest'] =
'next/dist/compiled/@mswjs/interceptors/ClientRequest'
export async function ncc_mswjs_interceptors(task, opts) {
await task
.source(
relative(__dirname, require.resolve('@mswjs/interceptors/ClientRequest'))
)
.ncc({
packageName: '@mswjs/interceptors/ClientRequest',
externals,
target: 'es5',
})
.target('src/compiled/@mswjs/interceptors/ClientRequest')
}
Integrating capsize latest (#47428) Integrating capsize latest <!-- 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(s) that you're making: ## For Contributors ### Improving Documentation or adding/fixing Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>
2023-03-27 05:29:28 +02:00
export async function capsize_metrics() {
const {
entireMetricsCollection,
// eslint-disable-next-line import/no-extraneous-dependencies
} = require('@capsizecss/metrics/entireMetricsCollection')
const outputPathDist = join(
__dirname,
'dist/server/capsize-font-metrics.json'
)
await writeJson(outputPathDist, entireMetricsCollection, { spaces: 2 })
Integrating capsize latest (#47428) Integrating capsize latest <!-- 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(s) that you're making: ## For Contributors ### Improving Documentation or adding/fixing Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>
2023-03-27 05:29:28 +02:00
}
// eslint-disable-next-line camelcase
externals['@babel/runtime'] = 'next/dist/compiled/@babel/runtime'
export async function copy_babel_runtime(task, opts) {
const runtimeDir = dirname(require.resolve('@babel/runtime/package.json'))
const outputDir = join(__dirname, 'src/compiled/@babel/runtime')
const runtimeFiles = glob.sync('**/*', {
cwd: runtimeDir,
ignore: ['node_modules/**/*'],
})
for (const file of runtimeFiles) {
const inputPath = join(runtimeDir, file)
const outputPath = join(outputDir, file)
if (!(await fs.stat(inputPath)).isFile()) {
continue
}
let contents = await fs.readFile(inputPath, 'utf8')
if (inputPath.endsWith('.js')) {
contents = contents
.replace(
'regenerator-runtime',
'next/dist/compiled/regenerator-runtime'
)
.replace('@babel/runtime', 'next/dist/compiled/@babel/runtime')
}
if (inputPath.endsWith('package.json')) {
contents = JSON.stringify({
...JSON.parse(contents),
dependencies: {},
})
}
await fs.mkdir(dirname(outputPath), { recursive: true })
await fs.writeFile(outputPath, contents)
}
}
externals['@vercel/og'] = 'next/dist/compiled/@vercel/og'
export async function copy_vercel_og(task, opts) {
await task
.source(
join(
relative(
__dirname,
dirname(require.resolve('@vercel/og/package.json'))
),
'{./dist/*.+(js|ttf|wasm),LICENSE}'
)
)
.target('src/compiled/@vercel/og')
await task
.source(
join(
relative(
__dirname,
dirname(require.resolve('@vercel/og/package.json'))
),
'./dist/index.*.js'
)
)
.target('src/compiled/@vercel/og')
// Types are not bundled, include satori types here
await task
.source(
join(dirname(require.resolve('satori/package.json')), 'dist/index.d.ts')
)
// eslint-disable-next-line require-yield
.run({ every: true }, function* (file) {
const source = file.data.toString()
// Ignore yoga-wasm-web types
file.data = source.replace(
/import { Yoga } from ['"]yoga-wasm-web['"]/g,
'type Yoga = any'
)
})
.target('src/compiled/@vercel/og/satori')
await task
.source(join(dirname(require.resolve('satori/package.json')), 'LICENSE'))
.target('src/compiled/@vercel/og/satori')
await task
.source(
join(
dirname(require.resolve('@vercel/og/package.json')),
'dist/**/*.d.ts'
)
)
// eslint-disable-next-line require-yield
.run({ every: true }, function* (file) {
const source = file.data.toString()
// Refers to copied satori types
file.data = source.replace(
/['"]satori['"]/g,
'"next/dist/compiled/@vercel/og/satori"'
)
})
.target('src/compiled/@vercel/og')
await writeJson(
join(__dirname, 'src/compiled/@vercel/og/package.json'),
{
name: '@vercel/og',
LICENSE: 'MLP-2.0',
type: 'module',
main: './index.node.js',
exports: {
'.': {
'edge-light': './index.edge.js',
import: './index.node.js',
node: './index.node.js',
default: './index.node.js',
},
},
},
{ spaces: 2 }
)
}
// eslint-disable-next-line camelcase
externals['node-fetch'] = 'next/dist/compiled/node-fetch'
export async function ncc_node_fetch(task, opts) {
await task
.source(relative(__dirname, require.resolve('node-fetch')))
.ncc({ packageName: 'node-fetch', externals })
.target('src/compiled/node-fetch')
}
externals['anser'] = 'next/dist/compiled/anser'
export async function ncc_node_anser(task, opts) {
await task
.source(relative(__dirname, require.resolve('anser')))
.ncc({ packageName: 'anser', externals })
.target('src/compiled/anser')
}
externals['stacktrace-parser'] = 'next/dist/compiled/stacktrace-parser'
export async function ncc_node_stacktrace_parser(task, opts) {
await task
.source(relative(__dirname, require.resolve('stacktrace-parser')))
.ncc({ packageName: 'stacktrace-parser', externals })
.target('src/compiled/stacktrace-parser')
}
externals['data-uri-to-buffer'] = 'next/dist/compiled/data-uri-to-buffer'
export async function ncc_node_data_uri_to_buffer(task, opts) {
await task
.source(relative(__dirname, require.resolve('data-uri-to-buffer')))
.ncc({ packageName: 'data-uri-to-buffer', externals })
.target('src/compiled/data-uri-to-buffer')
}
externals['css.escape'] = 'next/dist/compiled/css.escape'
export async function ncc_node_cssescape(task, opts) {
await task
.source(relative(__dirname, require.resolve('css.escape')))
.ncc({ packageName: 'css.escape', externals })
.target('src/compiled/css.escape')
}
externals['shell-quote'] = 'next/dist/compiled/shell-quote'
export async function ncc_node_shell_quote(task, opts) {
await task
.source(relative(__dirname, require.resolve('shell-quote')))
.ncc({ packageName: 'shell-quote', externals })
.target('src/compiled/shell-quote')
}
externals['platform'] = 'next/dist/compiled/platform'
export async function ncc_node_platform(task, opts) {
await task
.source(relative(__dirname, require.resolve('platform')))
.ncc({ packageName: 'platform', externals })
.target('src/compiled/platform')
const clientFile = join(__dirname, 'src/compiled/platform/platform.js')
const content = await fs.readFile(clientFile, 'utf8')
// remove AMD define branch as this forces the module to not
// be treated as commonjs
await fs.writeFile(
clientFile,
content.replace(
new RegExp(
'if(typeof define=="function"&&typeof define.amd=="object"&&define.amd){r.platform=d;define((function(){return d}))}else '.replace(
/[|\\{}()[\]^$+*?.-]/g,
'\\$&'
),
'g'
),
''
)
)
}
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
externals['undici'] = 'next/dist/compiled/undici'
export async function ncc_undici(task, opts) {
await task
.source(relative(__dirname, require.resolve('undici')))
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
.ncc({ packageName: 'undici', externals })
.target('src/compiled/undici')
const outputFile = join('src/compiled/undici/index.js')
await fs.writeFile(
outputFile,
(
await fs.readFile(outputFile, 'utf8')
).replace(/process\.emitWarning/g, 'void')
)
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
}
// eslint-disable-next-line camelcase
externals['acorn'] = 'next/dist/compiled/acorn'
export async function ncc_acorn(task, opts) {
await task
.source(relative(__dirname, require.resolve('acorn')))
.ncc({ packageName: 'acorn', externals })
.target('src/compiled/acorn')
}
// eslint-disable-next-line camelcase
externals['@edge-runtime/cookies'] = 'next/dist/compiled/@edge-runtime/cookies'
export async function ncc_edge_runtime_cookies() {
// `@edge-runtime/cookies` is precompiled and pre-bundled
// so we vendor the package as it is.
const dest = 'src/compiled/@edge-runtime/cookies'
const pkg = await readJson(
require.resolve('@edge-runtime/cookies/package.json')
)
await rmrf(dest)
await fs.mkdir(dest, { recursive: true })
await writeJson(join(dest, 'package.json'), {
name: '@edge-runtime/cookies',
version: pkg.version,
main: './index.js',
license: pkg.license,
})
await fs.cp(
require.resolve('@edge-runtime/cookies/dist/index.js'),
join(dest, 'index.js')
)
await fs.cp(
require.resolve('@edge-runtime/cookies/dist/index.d.ts'),
join(dest, 'index.d.ts')
)
}
// eslint-disable-next-line camelcase
externals['@edge-runtime/primitives'] =
'next/dist/compiled/@edge-runtime/primitives'
export async function ncc_edge_runtime_primitives() {
// `@edge-runtime/primitives` is precompiled and pre-bundled
// so we vendor the package as it is.
const dest = 'src/compiled/@edge-runtime/primitives'
await fs.mkdir(dest, { recursive: true })
const primitivesPath = dirname(
require.resolve('@edge-runtime/primitives/package.json')
)
const pkg = await readJson(
require.resolve('@edge-runtime/primitives/package.json')
)
await rmrf(dest)
for (const file of await fs.readdir(join(primitivesPath, 'types'))) {
await fs.cp(join(primitivesPath, 'types', file), join(dest, file))
}
for (const file of await fs.readdir(join(primitivesPath, 'dist'))) {
await fs.cp(join(primitivesPath, 'dist', file), join(dest, file))
}
await writeJson(join(dest, 'package.json'), {
name: '@edge-runtime/primitives',
version: pkg.version,
main: './index.js',
license: pkg.license,
})
await fs.cp(
require.resolve('@edge-runtime/primitives'),
join(dest, 'index.js')
)
await fs.cp(
require.resolve('@edge-runtime/primitives/types/index.d.ts'),
join(dest, 'index.d.ts')
)
}
// eslint-disable-next-line camelcase
externals['@edge-runtime/ponyfill'] =
'next/dist/compiled/@edge-runtime/ponyfill'
export async function ncc_edge_runtime_ponyfill(task, opts) {
const indexFile = await fs.readFile(
require.resolve('@edge-runtime/ponyfill/src/index.js'),
'utf8'
)
const dest = 'src/compiled/@edge-runtime/ponyfill'
await fs.mkdir(dest, { recursive: true })
await fs.writeFile(
join(dest, 'index.js'),
indexFile.replace(
`require('@edge-runtime/primitives')`,
`require(${JSON.stringify(externals['@edge-runtime/primitives'])})`
)
)
await fs.cp(
require.resolve('@edge-runtime/ponyfill/src/index.d.ts'),
join(dest, 'index.d.ts')
)
const pkg = await readJson(
require.resolve('@edge-runtime/ponyfill/package.json')
)
await writeJson(join(dest, 'package.json'), {
name: '@edge-runtime/ponyfill',
version: pkg.version,
main: './index.js',
types: './index.d.ts',
license: pkg.license,
})
}
// eslint-disable-next-line camelcase
externals['edge-runtime'] = 'next/dist/compiled/edge-runtime'
export async function ncc_edge_runtime(task, opts) {
const vmPath = resolveFrom(
dirname(require.resolve('edge-runtime')),
'@edge-runtime/vm/dist/edge-vm'
)
const content = await fs.readFile(vmPath, 'utf8')
// ensure ncc doesn't attempt to bundle dynamic requires
// so that they work at runtime correctly
await fs.writeFile(
vmPath,
content.replace(
/require\.resolve\('@edge-runtime\/primitives/g,
`__non_webpack_require__.resolve('next/dist/compiled/@edge-runtime/primitives`
)
)
await task
.source(relative(__dirname, require.resolve('edge-runtime')))
.ncc({ packageName: 'edge-runtime', externals })
.target('src/compiled/edge-runtime')
const outputFile = join(__dirname, 'src/compiled/edge-runtime/index.js')
await fs.writeFile(
outputFile,
(
await fs.readFile(outputFile, 'utf8')
).replace(/eval\("require"\)/g, 'require')
)
}
// eslint-disable-next-line camelcase
export async function ncc_next__react_dev_overlay(task, opts) {
const overlayExternals = {
...externals,
react: 'react',
'react-dom': 'react-dom',
}
// dev-overlay needs a newer source-map version
delete overlayExternals['source-map']
await task
.source(
relative(
__dirname,
require.resolve('@next/react-dev-overlay/dist/middleware')
)
)
.ncc({
precompiled: false,
packageName: '@next/react-dev-overlay',
externals: overlayExternals,
target: 'es5',
})
.target('dist/compiled/@next/react-dev-overlay/dist')
await task
.source(
relative(
__dirname,
require.resolve('@next/react-dev-overlay/dist/client')
)
)
.ncc({
precompiled: false,
packageName: '@next/react-dev-overlay',
externals: overlayExternals,
target: 'es5',
})
.target('dist/compiled/@next/react-dev-overlay/dist')
const clientFile = join(
__dirname,
'dist/compiled/@next/react-dev-overlay/dist/client.js'
)
const content = await fs.readFile(clientFile, 'utf8')
// remove AMD define branch as this forces the module to not
// be treated as commonjs
await fs.writeFile(
clientFile,
content.replace(
new RegExp(
'if(typeof define=="function"&&typeof define.amd=="object"&&define.amd){r.platform=b;define((function(){return b}))}else '.replace(
/[|\\{}()[\]^$+*?.-]/g,
'\\$&'
),
'g'
),
''
)
)
}
Add next/font import (#45891) Enables using `next/font` by adding `@next/font` as a dependency and reexporting its loaders. Always generates the `font-loader-manifest` as we can't know beforehand if the user intends to use `next/font` or not. Also adds telemetry for `next/font` usage. The tests are updated to use `next/font`. But `@next/font` is tested in `test/e2e/next-font/index.test.ts` and `test/e2e/app-dir/next-font` as well to ensure it doesn't break. Fixes NEXT-351 ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/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` - [ ] [e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md) ## Documentation / Examples - [ ] Make sure the linting passes by running `pnpm build && pnpm lint` - [ ] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
2023-02-16 15:33:39 +01:00
// eslint-disable-next-line camelcase
export async function ncc_next_font(task, opts) {
// `@next/font` can be copied as is, its only dependency is already NCCed
const destDir = join(__dirname, 'dist/compiled/@next/font')
const pkgPath = require.resolve('@next/font/package.json')
const pkg = await readJson(pkgPath)
Add next/font import (#45891) Enables using `next/font` by adding `@next/font` as a dependency and reexporting its loaders. Always generates the `font-loader-manifest` as we can't know beforehand if the user intends to use `next/font` or not. Also adds telemetry for `next/font` usage. The tests are updated to use `next/font`. But `@next/font` is tested in `test/e2e/next-font/index.test.ts` and `test/e2e/app-dir/next-font` as well to ensure it doesn't break. Fixes NEXT-351 ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/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` - [ ] [e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md) ## Documentation / Examples - [ ] Make sure the linting passes by running `pnpm build && pnpm lint` - [ ] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
2023-02-16 15:33:39 +01:00
const srcDir = dirname(pkgPath)
await rmrf(destDir)
await fs.mkdir(destDir, { recursive: true })
Add next/font import (#45891) Enables using `next/font` by adding `@next/font` as a dependency and reexporting its loaders. Always generates the `font-loader-manifest` as we can't know beforehand if the user intends to use `next/font` or not. Also adds telemetry for `next/font` usage. The tests are updated to use `next/font`. But `@next/font` is tested in `test/e2e/next-font/index.test.ts` and `test/e2e/app-dir/next-font` as well to ensure it doesn't break. Fixes NEXT-351 ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/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` - [ ] [e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md) ## Documentation / Examples - [ ] Make sure the linting passes by running `pnpm build && pnpm lint` - [ ] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
2023-02-16 15:33:39 +01:00
const files = glob.sync('{dist,google,local}/**/*.{js,json,d.ts}', {
cwd: srcDir,
})
for (const file of files) {
const outputFile = join(destDir, file)
await fs.mkdir(dirname(outputFile), { recursive: true })
await fs.cp(join(srcDir, file), outputFile)
Add next/font import (#45891) Enables using `next/font` by adding `@next/font` as a dependency and reexporting its loaders. Always generates the `font-loader-manifest` as we can't know beforehand if the user intends to use `next/font` or not. Also adds telemetry for `next/font` usage. The tests are updated to use `next/font`. But `@next/font` is tested in `test/e2e/next-font/index.test.ts` and `test/e2e/app-dir/next-font` as well to ensure it doesn't break. Fixes NEXT-351 ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/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` - [ ] [e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md) ## Documentation / Examples - [ ] Make sure the linting passes by running `pnpm build && pnpm lint` - [ ] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
2023-02-16 15:33:39 +01:00
}
await writeJson(join(destDir, 'package.json'), {
Add next/font import (#45891) Enables using `next/font` by adding `@next/font` as a dependency and reexporting its loaders. Always generates the `font-loader-manifest` as we can't know beforehand if the user intends to use `next/font` or not. Also adds telemetry for `next/font` usage. The tests are updated to use `next/font`. But `@next/font` is tested in `test/e2e/next-font/index.test.ts` and `test/e2e/app-dir/next-font` as well to ensure it doesn't break. Fixes NEXT-351 ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/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` - [ ] [e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md) ## Documentation / Examples - [ ] Make sure the linting passes by running `pnpm build && pnpm lint` - [ ] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
2023-02-16 15:33:39 +01:00
name: '@next/font',
license: pkg.license,
types: pkg.types,
})
}
// eslint-disable-next-line camelcase
Improve compile time on large application (#50792) ## What? While investigating slow compilation for a page on vercel.com in development I found that there was close to 10 seconds of time unaccounted for in `.next/trace`. Ran a profile and found that time was spent in watchpack `batch`, specifically calling `close` many times. When I tried to debug this further by running unbundled webpack I noticed the same issue didn't exists. ### Before <img width="1329" alt="Before" src="https://github.com/vercel/next.js/assets/6324199/9ace4628-db04-4de7-993f-65aef9dffc55"> ### After <img width="1278" alt="After" src="https://github.com/vercel/next.js/assets/6324199/55d5e58b-4a27-4235-8dea-723a7a78c117"> ## Raw numbers <table> <tr> <td>Before</td> <td>After</td> <td>Delta</td> <td>Delta (percent)</td> </tr> <tr> <td>13840 ms</td> <td>3580 ms</td> <td>-10260 ms</td> <td>-74.13%</td> </tr> </table> ## How? Investigated further and found that specifically not minifying watchpack solved the issue. <!-- 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(s) that you're making: ## For Contributors ### Improving Documentation or adding/fixing Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
2023-06-05 15:05:54 +02:00
externals['watchpack'] = 'watchpack'
// eslint-disable-next-line camelcase
externals['jest-worker'] = 'next/dist/compiled/jest-worker'
export async function ncc_jest_worker(task, opts) {
await rmrf(join(__dirname, 'src/compiled/jest-worker'))
await fs.mkdir(join(__dirname, 'src/compiled/jest-worker/workers'), {
recursive: true,
})
const workers = ['processChild.js', 'threadChild.js']
await task
.source(relative(__dirname, require.resolve('jest-worker')))
.ncc({ packageName: 'jest-worker', externals })
.target('src/compiled/jest-worker')
for (const worker of workers) {
const content = await fs.readFile(
join(
dirname(require.resolve('jest-worker/package.json')),
'build/workers',
worker
),
'utf8'
)
await fs.writeFile(
join(
dirname(require.resolve('jest-worker/package.json')),
'build/workers',
worker + '.tmp.js'
),
content.replace(/require\(file\)/g, '__non_webpack_require__(file)')
)
await task
.source(
relative(
__dirname,
join(
dirname(require.resolve('jest-worker/package.json')),
'build/workers',
worker + '.tmp.js'
)
)
)
.ncc({ externals })
.target('src/compiled/jest-worker/out')
await fs.rename(
join(__dirname, 'src/compiled/jest-worker/out', worker + '.tmp.js'),
join(__dirname, 'src/compiled/jest-worker', worker)
)
}
await rmrf(join(__dirname, 'src/compiled/jest-worker/workers'))
await rmrf(join(__dirname, 'src/compiled/jest-worker/out'))
}
// eslint-disable-next-line camelcase
export async function ncc_react_refresh_utils(task, opts) {
await rmrf(join(__dirname, 'dist/compiled/react-refresh'))
await fs.cp(
dirname(require.resolve('react-refresh/package.json')),
join(__dirname, 'dist/compiled/react-refresh'),
{ recursive: true, force: true }
)
const srcDir = join(
dirname(require.resolve('@next/react-refresh-utils/package.json')),
'dist'
)
const destDir = join(
__dirname,
'dist/compiled/@next/react-refresh-utils/dist'
)
await rmrf(destDir)
await fs.mkdir(destDir, { recursive: true })
const files = glob.sync('**/*.{js,json}', { cwd: srcDir })
for (const file of files) {
if (file === 'tsconfig.json') continue
const content = await fs.readFile(join(srcDir, file), 'utf8')
const outputFile = join(destDir, file)
await fs.mkdir(dirname(outputFile), { recursive: true })
await fs.writeFile(
outputFile,
content.replace(
/react-refresh\/runtime/g,
'next/dist/compiled/react-refresh/runtime'
)
)
}
}
// eslint-disable-next-line camelcase
externals['browserslist'] = 'next/dist/compiled/browserslist'
export async function ncc_browserslist(task, opts) {
const browserslistModule = require.resolve('browserslist')
const nodeFile = join(dirname(browserslistModule), 'node.js')
const content = await fs.readFile(nodeFile, 'utf8')
// ensure ncc doesn't attempt to bundle dynamic requires
// so that they work at runtime correctly
await fs.writeFile(
nodeFile,
content.replace(
/require\(require\.resolve\(/g,
`__non_webpack_require__(__non_webpack_require__.resolve(`
)
)
await task
.source(relative(__dirname, require.resolve('browserslist')))
.ncc({ packageName: 'browserslist', externals })
.target('src/compiled/browserslist')
await fs.writeFile(nodeFile, content)
}
// eslint-disable-next-line camelcase
externals['@napi-rs/triples'] = 'next/dist/compiled/@napi-rs/triples'
export async function ncc_napirs_triples(task, opts) {
await task
.source(relative(__dirname, require.resolve('@napi-rs/triples')))
.ncc({ packageName: '@napi-rs/triples', externals })
.target('src/compiled/@napi-rs/triples')
}
// eslint-disable-next-line camelcase
externals['p-limit'] = 'next/dist/compiled/p-limit'
export async function ncc_p_limit(task, opts) {
await task
.source(relative(__dirname, require.resolve('p-limit')))
.ncc({ packageName: 'p-limit', externals })
.target('src/compiled/p-limit')
}
// eslint-disable-next-line camelcase
externals['raw-body'] = 'next/dist/compiled/raw-body'
export async function ncc_raw_body(task, opts) {
await task
.source(relative(__dirname, require.resolve('raw-body')))
.ncc({ packageName: 'raw-body', externals })
.target('src/compiled/raw-body')
}
// eslint-disable-next-line camelcase
externals['image-size'] = 'next/dist/compiled/image-size'
export async function ncc_image_size(task, opts) {
await task
.source(relative(__dirname, require.resolve('image-size')))
.ncc({ packageName: 'image-size', externals })
.target('src/compiled/image-size')
}
// eslint-disable-next-line camelcase
externals['get-orientation'] = 'next/dist/compiled/get-orientation'
export async function ncc_get_orientation(task, opts) {
await task
.source(relative(__dirname, require.resolve('get-orientation')))
.ncc({ packageName: 'get-orientation', externals })
.target('src/compiled/get-orientation')
}
// eslint-disable-next-line camelcase
externals['@hapi/accept'] = 'next/dist/compiled/@hapi/accept'
export async function ncc_hapi_accept(task, opts) {
await task
.source(relative(__dirname, require.resolve('@hapi/accept')))
.ncc({ packageName: '@hapi/accept', externals })
.target('src/compiled/@hapi/accept')
}
2020-03-29 00:31:06 +01:00
// eslint-disable-next-line camelcase
externals['amphtml-validator'] = 'next/dist/compiled/amphtml-validator'
2020-03-29 00:31:06 +01:00
export async function ncc_amphtml_validator(task, opts) {
await task
.source(relative(__dirname, require.resolve('amphtml-validator')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'amphtml-validator', externals })
.target('src/compiled/amphtml-validator')
2020-03-29 00:31:06 +01:00
}
// eslint-disable-next-line camelcase
export async function ncc_assert(task, opts) {
await task
.source(relative(__dirname, require.resolve('assert/')))
.ncc({
packageName: 'assert',
externals,
mainFields: ['browser', 'main'],
target: 'es5',
})
.target('src/compiled/assert')
}
// eslint-disable-next-line camelcase
export async function ncc_browser_zlib(task, opts) {
await task
.source(relative(__dirname, require.resolve('browserify-zlib/')))
.ncc({
packageName: 'browserify-zlib',
externals,
mainFields: ['browser', 'main'],
target: 'es5',
})
.target('src/compiled/browserify-zlib')
}
// eslint-disable-next-line camelcase
export async function ncc_buffer(task, opts) {
await task
.source(relative(__dirname, require.resolve('buffer/')))
.ncc({
packageName: 'buffer',
externals,
mainFields: ['browser', 'main'],
target: 'es5',
})
.target('src/compiled/buffer')
}
// eslint-disable-next-line camelcase
export async function copy_react_is(task, opts) {
await task
.source(join(dirname(require.resolve('react-is/package.json')), '**/*'))
.target('src/compiled/react-is')
}
// eslint-disable-next-line camelcase
export async function copy_constants_browserify(task, opts) {
await fs.mkdir(join(__dirname, 'src/compiled/constants-browserify'), {
recursive: true,
})
await writeJson(
join(__dirname, 'src/compiled/constants-browserify/package.json'),
{ name: 'constants-browserify', main: './constants.json' }
)
await task
.source(require.resolve('constants-browserify'))
.target('src/compiled/constants-browserify')
}
// eslint-disable-next-line camelcase
export async function ncc_crypto_browserify(task, opts) {
await task
.source(relative(__dirname, require.resolve('crypto-browserify/')))
.ncc({
packageName: 'crypto-browserify',
externals,
mainFields: ['browser', 'main'],
target: 'es5',
})
.target('src/compiled/crypto-browserify')
}
// eslint-disable-next-line camelcase
export async function ncc_domain_browser(task, opts) {
await task
.source(relative(__dirname, require.resolve('domain-browser/')))
.ncc({
packageName: 'domain-browser',
externals,
mainFields: ['browser', 'main'],
target: 'es5',
})
.target('src/compiled/domain-browser')
}
// eslint-disable-next-line camelcase
export async function ncc_events(task, opts) {
await task
.source(relative(__dirname, require.resolve('events/')))
.ncc({
packageName: 'events',
externals,
mainFields: ['browser', 'main'],
target: 'es5',
})
.target('src/compiled/events')
}
// eslint-disable-next-line camelcase
export async function ncc_stream_browserify(task, opts) {
await task
.source(relative(__dirname, require.resolve('stream-browserify/')))
.ncc({
packageName: 'stream-browserify',
mainFields: ['browser', 'main'],
target: 'es5',
})
.target('src/compiled/stream-browserify')
// while ncc'ing readable-stream the browser mapping does not replace the
// require('stream') with require('events').EventEmitter correctly so we
// patch this manually as leaving require('stream') causes a circular
// reference breaking the browser polyfill
const outputFile = join(__dirname, 'src/compiled/stream-browserify/index.js')
await fs.writeFile(
outputFile,
(
await fs.readFile(outputFile, 'utf8')
).replace(`require("stream")`, `require("events").EventEmitter`)
)
}
// eslint-disable-next-line camelcase
export async function ncc_stream_http(task, opts) {
await task
.source(relative(__dirname, require.resolve('stream-http/')))
.ncc({
packageName: 'stream-http',
externals,
mainFields: ['browser', 'main'],
target: 'es5',
})
.target('src/compiled/stream-http')
}
// eslint-disable-next-line camelcase
export async function ncc_https_browserify(task, opts) {
await task
.source(relative(__dirname, require.resolve('https-browserify/')))
.ncc({
packageName: 'https-browserify',
externals,
mainFields: ['browser', 'main'],
target: 'es5',
})
.target('src/compiled/https-browserify')
}
// eslint-disable-next-line camelcase
export async function ncc_os_browserify(task, opts) {
await task
.source(relative(__dirname, require.resolve('os-browserify/browser')))
.ncc({
packageName: 'os-browserify',
externals,
mainFields: ['browser', 'main'],
target: 'es5',
})
.target('src/compiled/os-browserify')
}
// eslint-disable-next-line camelcase
export async function ncc_path_browserify(task, opts) {
await task
.source(relative(__dirname, require.resolve('path-browserify/')))
.ncc({
packageName: 'path-browserify',
externals,
mainFields: ['browser', 'main'],
target: 'es5',
})
.target('src/compiled/path-browserify')
const filePath = join(__dirname, 'src/compiled/path-browserify/index.js')
const content = await fs.readFile(filePath, 'utf8')
// Remove process usage from path-browserify polyfill for edge-runtime
await fs.writeFile(filePath, content.replace(/process\.cwd\(\)/g, '""'))
}
// eslint-disable-next-line camelcase
export async function ncc_process(task, opts) {
await task
.source(relative(__dirname, require.resolve('process/browser')))
.ncc({
packageName: 'process',
externals,
mainFields: ['browser', 'main'],
target: 'es5',
})
.target('src/compiled/process')
}
// eslint-disable-next-line camelcase
export async function ncc_querystring_es3(task, opts) {
await task
.source(relative(__dirname, require.resolve('querystring-es3/')))
.ncc({
packageName: 'querystring-es3',
externals,
mainFields: ['browser', 'main'],
target: 'es5',
})
.target('src/compiled/querystring-es3')
}
// eslint-disable-next-line camelcase
export async function ncc_string_decoder(task, opts) {
await task
.source(relative(__dirname, require.resolve('string_decoder/')))
.ncc({
packageName: 'string_decoder',
externals,
mainFields: ['browser', 'main'],
target: 'es5',
})
.target('src/compiled/string_decoder')
}
// eslint-disable-next-line camelcase
export async function ncc_util(task, opts) {
await task
.source(relative(__dirname, require.resolve('util/')))
.ncc({
packageName: 'util',
externals,
mainFields: ['browser', 'main'],
target: 'es5',
})
.target('src/compiled/util')
}
// eslint-disable-next-line camelcase
export async function ncc_punycode(task, opts) {
await task
.source(relative(__dirname, require.resolve('punycode/')))
.ncc({
packageName: 'punycode',
externals,
mainFields: ['browser', 'main'],
target: 'es5',
})
.target('src/compiled/punycode')
}
// eslint-disable-next-line camelcase
export async function ncc_set_immediate(task, opts) {
await task
.source(relative(__dirname, require.resolve('setimmediate/')))
.ncc({
packageName: 'setimmediate',
externals,
mainFields: ['browser', 'main'],
target: 'es5',
})
.target('src/compiled/setimmediate')
}
// eslint-disable-next-line camelcase
export async function ncc_timers_browserify(task, opts) {
await task
.source(relative(__dirname, require.resolve('timers-browserify/')))
.ncc({
packageName: 'timers-browserify',
externals: {
...externals,
setimmediate: 'next/dist/compiled/setimmediate',
},
mainFields: ['browser', 'main'],
target: 'es5',
})
.target('src/compiled/timers-browserify')
}
// eslint-disable-next-line camelcase
export async function ncc_tty_browserify(task, opts) {
await task
.source(relative(__dirname, require.resolve('tty-browserify/')))
.ncc({
packageName: 'tty-browserify',
externals,
mainFields: ['browser', 'main'],
target: 'es5',
})
.target('src/compiled/tty-browserify')
}
// eslint-disable-next-line camelcase
export async function ncc_vm_browserify(task, opts) {
await task
.source(relative(__dirname, require.resolve('vm-browserify/')))
.ncc({
packageName: 'vm-browserify',
externals,
mainFields: ['browser', 'main'],
target: 'es5',
})
.target('src/compiled/vm-browserify')
}
// eslint-disable-next-line camelcase
externals['@ampproject/toolbox-optimizer'] =
'next/dist/compiled/@ampproject/toolbox-optimizer'
export async function ncc_amp_optimizer(task, opts) {
await task
.source(
relative(__dirname, require.resolve('@ampproject/toolbox-optimizer'))
)
.ncc({
externals,
precompiled: false,
packageName: '@ampproject/toolbox-optimizer',
})
.target('dist/compiled/@ampproject/toolbox-optimizer')
}
// eslint-disable-next-line camelcase
externals['arg'] = 'next/dist/compiled/arg'
export async function ncc_arg(task, opts) {
await task
.source(relative(__dirname, require.resolve('arg')))
.ncc({ packageName: 'arg' })
.target('src/compiled/arg')
}
2019-02-27 15:22:18 +01:00
// eslint-disable-next-line camelcase
externals['async-retry'] = 'next/dist/compiled/async-retry'
2020-03-29 00:27:09 +01:00
export async function ncc_async_retry(task, opts) {
await task
.source(relative(__dirname, require.resolve('async-retry')))
2020-03-29 01:53:00 +01:00
.ncc({
packageName: 'async-retry',
2020-03-29 18:16:32 +02:00
externals,
2020-03-29 01:53:00 +01:00
})
.target('src/compiled/async-retry')
2020-03-29 00:27:09 +01:00
}
// eslint-disable-next-line camelcase
externals['async-sema'] = 'next/dist/compiled/async-sema'
2020-03-29 00:27:09 +01:00
export async function ncc_async_sema(task, opts) {
await task
.source(relative(__dirname, require.resolve('async-sema')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'async-sema', externals })
.target('src/compiled/async-sema')
2020-03-29 00:27:09 +01:00
}
externals['postcss-plugin-stub-for-cssnano-simple'] =
'next/dist/compiled/postcss-plugin-stub-for-cssnano-simple'
// eslint-disable-next-line camelcase
export async function ncc_postcss_plugin_stub_for_cssnano_simple(task, opts) {
await task
.source('src/bundles/postcss-plugin-stub/index.js')
.ncc({
externals,
})
.target('src/compiled/postcss-plugin-stub-for-cssnano-simple')
}
const babelCorePackages = {
'code-frame': 'next/dist/compiled/babel/code-frame',
'@babel/generator': 'next/dist/compiled/babel/generator',
'@babel/traverse': 'next/dist/compiled/babel/traverse',
'@babel/types': 'next/dist/compiled/babel/types',
'@babel/core': 'next/dist/compiled/babel/core',
'@babel/parser': 'next/dist/compiled/babel/parser',
'@babel/core/lib/config': 'next/dist/compiled/babel/core-lib-config',
'@babel/core/lib/transformation/normalize-file':
'next/dist/compiled/babel/core-lib-normalize-config',
'@babel/core/lib/transformation/normalize-opts':
'next/dist/compiled/babel/core-lib-normalize-opts',
'@babel/core/lib/transformation/block-hoist-plugin':
'next/dist/compiled/babel/core-lib-block-hoisting-plugin',
'@babel/core/lib/transformation/plugin-pass':
'next/dist/compiled/babel/core-lib-plugin-pass',
}
Object.assign(externals, babelCorePackages)
// eslint-disable-next-line camelcase
export async function ncc_babel_bundle(task, opts) {
const bundleExternals = {
...externals,
'next/dist/compiled/babel-packages': 'next/dist/compiled/babel-packages',
}
for (const pkg of Object.keys(babelCorePackages)) {
delete bundleExternals[pkg]
}
await task
.source('src/bundles/babel/bundle.js')
.ncc({
packageName: '@babel/core',
bundleName: 'babel',
externals: bundleExternals,
})
.target('src/compiled/babel')
}
// eslint-disable-next-line camelcase
export async function ncc_babel_bundle_packages(task, opts) {
const eslintParseFile = join(
dirname(require.resolve('@babel/eslint-parser')),
'./parse.cjs'
)
const content = await fs.readFile(eslintParseFile, 'utf-8')
// Let parser.cjs require @babel/parser directly
const replacedContent = content
.replace(
`const babelParser = require((`,
`function noop(){};\nconst babelParser = require('@babel/parser');noop((`
)
.replace(/require.resolve/g, 'noop')
await fs.writeFile(eslintParseFile, replacedContent)
await task
.source('src/bundles/babel/packages-bundle.js')
.ncc({
externals: externals,
})
.target(`src/compiled/babel-packages`)
await writeJson(join(__dirname, 'src/compiled/babel-packages/package.json'), {
name: 'babel-packages',
main: './packages-bundle.js',
})
await task.source('src/bundles/babel/packages/*').target('src/compiled/babel')
}
externals['cssnano-simple'] = 'next/dist/compiled/cssnano-simple'
// eslint-disable-next-line camelcase
export async function ncc_cssnano_simple_bundle(task, opts) {
const bundleExternals = {
...externals,
'postcss-svgo': 'next/dist/compiled/postcss-plugin-stub-for-cssnano-simple',
}
await task
.source('src/bundles/cssnano-simple/index.js')
.ncc({
externals: bundleExternals,
})
.target('src/compiled/cssnano-simple')
}
// eslint-disable-next-line camelcase
externals['bytes'] = 'next/dist/compiled/bytes'
export async function ncc_bytes(task, opts) {
await task
.source(relative(__dirname, require.resolve('bytes')))
.ncc({ packageName: 'bytes', externals })
.target('src/compiled/bytes')
}
// eslint-disable-next-line camelcase
externals['ci-info'] = 'next/dist/compiled/ci-info'
2020-03-29 00:43:52 +01:00
export async function ncc_ci_info(task, opts) {
await task
.source(relative(__dirname, require.resolve('ci-info')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'ci-info', externals })
.target('src/compiled/ci-info')
2020-03-29 00:43:52 +01:00
}
[ESLint] Introduce a new setup process when `next lint` is run for the first time (#26584) This PR introduces an improved developer experience when `next lint` is run for the first time. ### Current behavior `eslint-config-next` is a required package that must be installed before proceeding with `next lint` or `next build`: ![image](https://user-images.githubusercontent.com/12476932/123468791-43088100-d5c0-11eb-9ad0-5beb80b6c968.png) Although this has helped many developers start using the new ESLint config, this has also resulted in a few issues: - Users are required to install the full config (`eslint-config-next`) even if they do not use it or use the Next.js plugin directly (`eslint-plugin-next`). - #26348 - There's some confusion on why `eslint-config-next` needs to be installed or how it should be used instead of `eslint-plugin-next`. - #26574 - #26475 - #26438 ### New behavior Instead of enforcing `eslint-config-next` as a required package, this PR prompts the user by asking what config they would like to start. This happens when `next lint` is run for the first time **and** if no ESLint configuration is detected in the application. <img src="https://user-images.githubusercontent.com/12476932/124331177-e1668a80-db5c-11eb-8915-38d3dc20f5d4.gif" width="800" /> - The CLI will take care of installing `eslint` or `eslint-config-next` if either is not already installed - Users now have the option to choose between a strict configuration (`next/core-web-vitals`) or just the base configuration (`next`) - For users that decide to create their own ESLint configuration, or already have an existing one, **installing `eslint-config-next` will not be a requirement for `next lint` or `next build` to run**. A warning message will just show if the Next.js ESLint plugin is not detected in an ESLint config. <img width="682" alt="Screen Shot 2021-06-25 at 3 02 12 PM" src="https://user-images.githubusercontent.com/12476932/123473329-6cc4a680-d5c6-11eb-9a57-d5c0b89a2732.png"> --- In addition, this PR also: - Fixes #26348 - Updates documentation to make it more clear what approach to take for new and existing ESLint configurations
2021-08-04 23:53:15 +02:00
// eslint-disable-next-line camelcase
externals['cli-select'] = 'next/dist/compiled/cli-select'
export async function ncc_cli_select(task, opts) {
await task
.source(relative(__dirname, require.resolve('cli-select')))
[ESLint] Introduce a new setup process when `next lint` is run for the first time (#26584) This PR introduces an improved developer experience when `next lint` is run for the first time. ### Current behavior `eslint-config-next` is a required package that must be installed before proceeding with `next lint` or `next build`: ![image](https://user-images.githubusercontent.com/12476932/123468791-43088100-d5c0-11eb-9ad0-5beb80b6c968.png) Although this has helped many developers start using the new ESLint config, this has also resulted in a few issues: - Users are required to install the full config (`eslint-config-next`) even if they do not use it or use the Next.js plugin directly (`eslint-plugin-next`). - #26348 - There's some confusion on why `eslint-config-next` needs to be installed or how it should be used instead of `eslint-plugin-next`. - #26574 - #26475 - #26438 ### New behavior Instead of enforcing `eslint-config-next` as a required package, this PR prompts the user by asking what config they would like to start. This happens when `next lint` is run for the first time **and** if no ESLint configuration is detected in the application. <img src="https://user-images.githubusercontent.com/12476932/124331177-e1668a80-db5c-11eb-8915-38d3dc20f5d4.gif" width="800" /> - The CLI will take care of installing `eslint` or `eslint-config-next` if either is not already installed - Users now have the option to choose between a strict configuration (`next/core-web-vitals`) or just the base configuration (`next`) - For users that decide to create their own ESLint configuration, or already have an existing one, **installing `eslint-config-next` will not be a requirement for `next lint` or `next build` to run**. A warning message will just show if the Next.js ESLint plugin is not detected in an ESLint config. <img width="682" alt="Screen Shot 2021-06-25 at 3 02 12 PM" src="https://user-images.githubusercontent.com/12476932/123473329-6cc4a680-d5c6-11eb-9a57-d5c0b89a2732.png"> --- In addition, this PR also: - Fixes #26348 - Updates documentation to make it more clear what approach to take for new and existing ESLint configurations
2021-08-04 23:53:15 +02:00
.ncc({ packageName: 'cli-select', externals })
.target('src/compiled/cli-select')
[ESLint] Introduce a new setup process when `next lint` is run for the first time (#26584) This PR introduces an improved developer experience when `next lint` is run for the first time. ### Current behavior `eslint-config-next` is a required package that must be installed before proceeding with `next lint` or `next build`: ![image](https://user-images.githubusercontent.com/12476932/123468791-43088100-d5c0-11eb-9ad0-5beb80b6c968.png) Although this has helped many developers start using the new ESLint config, this has also resulted in a few issues: - Users are required to install the full config (`eslint-config-next`) even if they do not use it or use the Next.js plugin directly (`eslint-plugin-next`). - #26348 - There's some confusion on why `eslint-config-next` needs to be installed or how it should be used instead of `eslint-plugin-next`. - #26574 - #26475 - #26438 ### New behavior Instead of enforcing `eslint-config-next` as a required package, this PR prompts the user by asking what config they would like to start. This happens when `next lint` is run for the first time **and** if no ESLint configuration is detected in the application. <img src="https://user-images.githubusercontent.com/12476932/124331177-e1668a80-db5c-11eb-8915-38d3dc20f5d4.gif" width="800" /> - The CLI will take care of installing `eslint` or `eslint-config-next` if either is not already installed - Users now have the option to choose between a strict configuration (`next/core-web-vitals`) or just the base configuration (`next`) - For users that decide to create their own ESLint configuration, or already have an existing one, **installing `eslint-config-next` will not be a requirement for `next lint` or `next build` to run**. A warning message will just show if the Next.js ESLint plugin is not detected in an ESLint config. <img width="682" alt="Screen Shot 2021-06-25 at 3 02 12 PM" src="https://user-images.githubusercontent.com/12476932/123473329-6cc4a680-d5c6-11eb-9a57-d5c0b89a2732.png"> --- In addition, this PR also: - Fixes #26348 - Updates documentation to make it more clear what approach to take for new and existing ESLint configurations
2021-08-04 23:53:15 +02:00
}
externals['comment-json'] = 'next/dist/compiled/comment-json'
export async function ncc_comment_json(task, opts) {
await task
.source(relative(__dirname, require.resolve('comment-json')))
.ncc({ packageName: 'comment-json', externals })
.target('src/compiled/comment-json')
}
2020-03-29 00:43:52 +01:00
// eslint-disable-next-line camelcase
externals['compression'] = 'next/dist/compiled/compression'
2020-03-29 00:56:38 +01:00
export async function ncc_compression(task, opts) {
await task
.source(relative(__dirname, require.resolve('compression')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'compression', externals })
.target('src/compiled/compression')
2020-03-29 00:56:38 +01:00
}
// eslint-disable-next-line camelcase
externals['conf'] = 'next/dist/compiled/conf'
2020-03-29 17:46:33 +02:00
export async function ncc_conf(task, opts) {
await task
.source(relative(__dirname, require.resolve('conf')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'conf', externals })
.target('src/compiled/conf')
2020-03-29 17:46:33 +02:00
}
// eslint-disable-next-line camelcase
externals['content-disposition'] = 'next/dist/compiled/content-disposition'
export async function ncc_content_disposition(task, opts) {
await task
.source(relative(__dirname, require.resolve('content-disposition')))
.ncc({ packageName: 'content-disposition', externals })
.target('src/compiled/content-disposition')
}
// eslint-disable-next-line camelcase
externals['content-type'] = 'next/dist/compiled/content-type'
2020-03-29 00:56:38 +01:00
export async function ncc_content_type(task, opts) {
await task
.source(relative(__dirname, require.resolve('content-type')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'content-type', externals })
.target('src/compiled/content-type')
2020-03-29 00:56:38 +01:00
}
// eslint-disable-next-line camelcase
externals['cookie'] = 'next/dist/compiled/cookie'
2020-03-29 01:02:03 +01:00
export async function ncc_cookie(task, opts) {
await task
.source(relative(__dirname, require.resolve('cookie')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'cookie', externals })
.target('src/compiled/cookie')
2020-03-29 01:02:03 +01:00
}
// eslint-disable-next-line camelcase
[ESLint] Introduce a new setup process when `next lint` is run for the first time (#26584) This PR introduces an improved developer experience when `next lint` is run for the first time. ### Current behavior `eslint-config-next` is a required package that must be installed before proceeding with `next lint` or `next build`: ![image](https://user-images.githubusercontent.com/12476932/123468791-43088100-d5c0-11eb-9ad0-5beb80b6c968.png) Although this has helped many developers start using the new ESLint config, this has also resulted in a few issues: - Users are required to install the full config (`eslint-config-next`) even if they do not use it or use the Next.js plugin directly (`eslint-plugin-next`). - #26348 - There's some confusion on why `eslint-config-next` needs to be installed or how it should be used instead of `eslint-plugin-next`. - #26574 - #26475 - #26438 ### New behavior Instead of enforcing `eslint-config-next` as a required package, this PR prompts the user by asking what config they would like to start. This happens when `next lint` is run for the first time **and** if no ESLint configuration is detected in the application. <img src="https://user-images.githubusercontent.com/12476932/124331177-e1668a80-db5c-11eb-8915-38d3dc20f5d4.gif" width="800" /> - The CLI will take care of installing `eslint` or `eslint-config-next` if either is not already installed - Users now have the option to choose between a strict configuration (`next/core-web-vitals`) or just the base configuration (`next`) - For users that decide to create their own ESLint configuration, or already have an existing one, **installing `eslint-config-next` will not be a requirement for `next lint` or `next build` to run**. A warning message will just show if the Next.js ESLint plugin is not detected in an ESLint config. <img width="682" alt="Screen Shot 2021-06-25 at 3 02 12 PM" src="https://user-images.githubusercontent.com/12476932/123473329-6cc4a680-d5c6-11eb-9a57-d5c0b89a2732.png"> --- In addition, this PR also: - Fixes #26348 - Updates documentation to make it more clear what approach to take for new and existing ESLint configurations
2021-08-04 23:53:15 +02:00
externals['cross-spawn'] = 'next/dist/compiled/cross-spawn'
export async function ncc_cross_spawn(task, opts) {
await task
.source(relative(__dirname, require.resolve('cross-spawn')))
[ESLint] Introduce a new setup process when `next lint` is run for the first time (#26584) This PR introduces an improved developer experience when `next lint` is run for the first time. ### Current behavior `eslint-config-next` is a required package that must be installed before proceeding with `next lint` or `next build`: ![image](https://user-images.githubusercontent.com/12476932/123468791-43088100-d5c0-11eb-9ad0-5beb80b6c968.png) Although this has helped many developers start using the new ESLint config, this has also resulted in a few issues: - Users are required to install the full config (`eslint-config-next`) even if they do not use it or use the Next.js plugin directly (`eslint-plugin-next`). - #26348 - There's some confusion on why `eslint-config-next` needs to be installed or how it should be used instead of `eslint-plugin-next`. - #26574 - #26475 - #26438 ### New behavior Instead of enforcing `eslint-config-next` as a required package, this PR prompts the user by asking what config they would like to start. This happens when `next lint` is run for the first time **and** if no ESLint configuration is detected in the application. <img src="https://user-images.githubusercontent.com/12476932/124331177-e1668a80-db5c-11eb-8915-38d3dc20f5d4.gif" width="800" /> - The CLI will take care of installing `eslint` or `eslint-config-next` if either is not already installed - Users now have the option to choose between a strict configuration (`next/core-web-vitals`) or just the base configuration (`next`) - For users that decide to create their own ESLint configuration, or already have an existing one, **installing `eslint-config-next` will not be a requirement for `next lint` or `next build` to run**. A warning message will just show if the Next.js ESLint plugin is not detected in an ESLint config. <img width="682" alt="Screen Shot 2021-06-25 at 3 02 12 PM" src="https://user-images.githubusercontent.com/12476932/123473329-6cc4a680-d5c6-11eb-9a57-d5c0b89a2732.png"> --- In addition, this PR also: - Fixes #26348 - Updates documentation to make it more clear what approach to take for new and existing ESLint configurations
2021-08-04 23:53:15 +02:00
.ncc({ packageName: 'cross-spawn', externals })
.target('src/compiled/cross-spawn')
[ESLint] Introduce a new setup process when `next lint` is run for the first time (#26584) This PR introduces an improved developer experience when `next lint` is run for the first time. ### Current behavior `eslint-config-next` is a required package that must be installed before proceeding with `next lint` or `next build`: ![image](https://user-images.githubusercontent.com/12476932/123468791-43088100-d5c0-11eb-9ad0-5beb80b6c968.png) Although this has helped many developers start using the new ESLint config, this has also resulted in a few issues: - Users are required to install the full config (`eslint-config-next`) even if they do not use it or use the Next.js plugin directly (`eslint-plugin-next`). - #26348 - There's some confusion on why `eslint-config-next` needs to be installed or how it should be used instead of `eslint-plugin-next`. - #26574 - #26475 - #26438 ### New behavior Instead of enforcing `eslint-config-next` as a required package, this PR prompts the user by asking what config they would like to start. This happens when `next lint` is run for the first time **and** if no ESLint configuration is detected in the application. <img src="https://user-images.githubusercontent.com/12476932/124331177-e1668a80-db5c-11eb-8915-38d3dc20f5d4.gif" width="800" /> - The CLI will take care of installing `eslint` or `eslint-config-next` if either is not already installed - Users now have the option to choose between a strict configuration (`next/core-web-vitals`) or just the base configuration (`next`) - For users that decide to create their own ESLint configuration, or already have an existing one, **installing `eslint-config-next` will not be a requirement for `next lint` or `next build` to run**. A warning message will just show if the Next.js ESLint plugin is not detected in an ESLint config. <img width="682" alt="Screen Shot 2021-06-25 at 3 02 12 PM" src="https://user-images.githubusercontent.com/12476932/123473329-6cc4a680-d5c6-11eb-9a57-d5c0b89a2732.png"> --- In addition, this PR also: - Fixes #26348 - Updates documentation to make it more clear what approach to take for new and existing ESLint configurations
2021-08-04 23:53:15 +02:00
}
// eslint-disable-next-line camelcase
externals['debug'] = 'next/dist/compiled/debug'
export async function ncc_debug(task, opts) {
await task
.source(relative(__dirname, require.resolve('debug')))
.ncc({ packageName: 'debug', externals })
.target('src/compiled/debug')
}
// eslint-disable-next-line camelcase
externals['devalue'] = 'next/dist/compiled/devalue'
2020-03-29 01:18:22 +01:00
export async function ncc_devalue(task, opts) {
await task
.source(relative(__dirname, require.resolve('devalue')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'devalue', externals })
.target('src/compiled/devalue')
2020-03-29 01:18:22 +01:00
}
2020-03-30 03:30:55 +02:00
// eslint-disable-next-line camelcase
externals['find-cache-dir'] = 'next/dist/compiled/find-cache-dir'
export async function ncc_find_cache_dir(task, opts) {
await task
.source(relative(__dirname, require.resolve('find-cache-dir')))
.ncc({ packageName: 'find-cache-dir', externals })
.target('src/compiled/find-cache-dir')
}
// eslint-disable-next-line camelcase
externals['find-up'] = 'next/dist/compiled/find-up'
2020-03-29 18:21:53 +02:00
export async function ncc_find_up(task, opts) {
await task
.source(relative(__dirname, require.resolve('find-up')))
2020-03-29 18:21:53 +02:00
.ncc({ packageName: 'find-up', externals })
.target('src/compiled/find-up')
2020-03-29 18:21:53 +02:00
}
// eslint-disable-next-line camelcase
externals['fresh'] = 'next/dist/compiled/fresh'
2020-03-29 01:27:13 +01:00
export async function ncc_fresh(task, opts) {
await task
.source(relative(__dirname, require.resolve('fresh')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'fresh', externals })
.target('src/compiled/fresh')
2020-03-29 01:27:13 +01:00
}
// eslint-disable-next-line camelcase
externals['glob'] = 'next/dist/compiled/glob'
export async function ncc_glob(task, opts) {
await task
.source(relative(__dirname, require.resolve('glob')))
.ncc({ packageName: 'glob', externals })
.target('src/compiled/glob')
}
// eslint-disable-next-line camelcase
externals['gzip-size'] = 'next/dist/compiled/gzip-size'
2020-03-29 01:29:14 +01:00
export async function ncc_gzip_size(task, opts) {
await task
.source(relative(__dirname, require.resolve('gzip-size')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'gzip-size', externals })
.target('src/compiled/gzip-size')
2020-03-29 01:29:14 +01:00
}
// eslint-disable-next-line camelcase
externals['http-proxy'] = 'next/dist/compiled/http-proxy'
2020-03-29 01:30:34 +01:00
export async function ncc_http_proxy(task, opts) {
await task
.source(relative(__dirname, require.resolve('http-proxy')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'http-proxy', externals })
.target('src/compiled/http-proxy')
2020-03-29 01:30:34 +01:00
}
// eslint-disable-next-line camelcase
2020-03-30 03:37:41 +02:00
externals['ignore-loader'] = 'next/dist/compiled/ignore-loader'
export async function ncc_ignore_loader(task, opts) {
await task
.source(relative(__dirname, require.resolve('ignore-loader')))
2020-03-30 03:37:41 +02:00
.ncc({ packageName: 'ignore-loader', externals })
.target('src/compiled/ignore-loader')
2020-03-30 03:37:41 +02:00
}
// eslint-disable-next-line camelcase
externals['is-animated'] = 'next/dist/compiled/is-animated'
export async function ncc_is_animated(task, opts) {
await task
.source(relative(__dirname, require.resolve('is-animated')))
.ncc({ packageName: 'is-animated', externals })
.target('src/compiled/is-animated')
}
// eslint-disable-next-line camelcase
externals['is-docker'] = 'next/dist/compiled/is-docker'
2020-03-29 01:33:35 +01:00
export async function ncc_is_docker(task, opts) {
await task
.source(relative(__dirname, require.resolve('is-docker')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'is-docker', externals })
.target('src/compiled/is-docker')
2020-03-29 01:33:35 +01:00
}
// eslint-disable-next-line camelcase
externals['is-wsl'] = 'next/dist/compiled/is-wsl'
2020-03-29 01:33:35 +01:00
export async function ncc_is_wsl(task, opts) {
await task
.source(relative(__dirname, require.resolve('is-wsl')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'is-wsl', externals })
.target('src/compiled/is-wsl')
2020-03-29 01:33:35 +01:00
}
// eslint-disable-next-line camelcase
externals['json5'] = 'next/dist/compiled/json5'
2020-03-29 01:36:15 +01:00
export async function ncc_json5(task, opts) {
await task
.source(relative(__dirname, require.resolve('json5')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'json5', externals })
.target('src/compiled/json5')
2020-03-29 01:36:15 +01:00
}
// eslint-disable-next-line camelcase
externals['jsonwebtoken'] = 'next/dist/compiled/jsonwebtoken'
2020-03-29 01:37:45 +01:00
export async function ncc_jsonwebtoken(task, opts) {
await task
.source(relative(__dirname, require.resolve('jsonwebtoken')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'jsonwebtoken', externals })
.target('src/compiled/jsonwebtoken')
2020-03-29 01:37:45 +01:00
}
// eslint-disable-next-line camelcase
Add `loader-runner` to compiled packages (#45962) This adds `loader-runner` to the compiled packages distributed with Next.js This is a dependency of Turbopack's webpack loader support. Currently, users have to manually install `loader-runner` in their application to use webpack loaders with Turbopack. This will allow Turbopack to require loader-runner from within the installed version of Next.js instead. Test Plan: `require('./packages/next/dist/compiled/loader-runner/')` <!-- 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(s) that you're making: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/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` - [ ] [e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md) ## Documentation / Examples - [ ] Make sure the linting passes by running `pnpm build && pnpm lint` - [ ] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md) --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>
2023-02-18 07:24:40 +01:00
externals['loader-runner'] = 'next/dist/compiled/loader-runner'
export async function ncc_loader_runner(task, opts) {
await task
.source(relative(__dirname, require.resolve('loader-runner')))
.ncc({ packageName: 'loader-runner', externals })
.target('src/compiled/loader-runner')
}
// eslint-disable-next-line camelcase
externals['loader-utils'] = 'error loader-utils version not specified'
externals['loader-utils2'] = 'next/dist/compiled/loader-utils2'
export async function ncc_loader_utils2(task, opts) {
await task
.source(relative(__dirname, require.resolve('loader-utils2')))
.ncc({ packageName: 'loader-utils2', externals })
.target('src/compiled/loader-utils2')
}
// eslint-disable-next-line camelcase
externals['loader-utils3'] = 'next/dist/compiled/loader-utils3'
export async function ncc_loader_utils3(task, opts) {
await task
.source(relative(__dirname, require.resolve('loader-utils3')))
.ncc({ packageName: 'loader-utils3', externals })
.target('src/compiled/loader-utils3')
}
// eslint-disable-next-line camelcase
externals['lodash.curry'] = 'next/dist/compiled/lodash.curry'
2020-03-29 01:43:59 +01:00
export async function ncc_lodash_curry(task, opts) {
await task
.source(relative(__dirname, require.resolve('lodash.curry')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'lodash.curry', externals })
.target('src/compiled/lodash.curry')
2020-03-29 01:43:59 +01:00
}
// eslint-disable-next-line camelcase
externals['lru-cache'] = 'next/dist/compiled/lru-cache'
2020-03-29 01:46:22 +01:00
export async function ncc_lru_cache(task, opts) {
await task
.source(relative(__dirname, require.resolve('lru-cache')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'lru-cache', externals })
.target('src/compiled/lru-cache')
2020-03-29 01:46:22 +01:00
}
// eslint-disable-next-line camelcase
externals['nanoid'] = 'next/dist/compiled/nanoid'
export async function ncc_nanoid(task, opts) {
await task
.source(relative(__dirname, require.resolve('nanoid')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'nanoid', externals })
.target('src/compiled/nanoid')
}
// eslint-disable-next-line camelcase
externals['native-url'] = 'next/dist/compiled/native-url'
export async function ncc_native_url(task, opts) {
await task
.source(relative(__dirname, require.resolve('native-url')))
.ncc({
packageName: 'native-url',
externals: {
...externals,
querystring: 'next/dist/compiled/querystring-es3',
},
target: 'es5',
})
.target('src/compiled/native-url')
}
// eslint-disable-next-line camelcase
externals['neo-async'] = 'next/dist/compiled/neo-async'
export async function ncc_neo_async(task, opts) {
await task
.source(relative(__dirname, require.resolve('neo-async')))
.ncc({ packageName: 'neo-async', externals })
.target('src/compiled/neo-async')
}
// eslint-disable-next-line camelcase
externals['ora'] = 'next/dist/compiled/ora'
2020-03-29 01:53:00 +01:00
export async function ncc_ora(task, opts) {
await task
.source(relative(__dirname, require.resolve('ora')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'ora', externals })
.target('src/compiled/ora')
2020-03-29 01:53:00 +01:00
}
// eslint-disable-next-line camelcase
2020-03-30 04:01:30 +02:00
externals['postcss-flexbugs-fixes'] =
'next/dist/compiled/postcss-flexbugs-fixes'
export async function ncc_postcss_flexbugs_fixes(task, opts) {
await task
.source(relative(__dirname, require.resolve('postcss-flexbugs-fixes')))
2020-03-30 04:01:30 +02:00
.ncc({ packageName: 'postcss-flexbugs-fixes', externals })
.target('src/compiled/postcss-flexbugs-fixes')
2020-03-30 04:01:30 +02:00
}
// eslint-disable-next-line camelcase
export async function ncc_postcss_safe_parser(task, opts) {
2020-03-30 04:01:30 +02:00
await task
.source(relative(__dirname, require.resolve('postcss-safe-parser')))
.ncc({ packageName: 'postcss-safe-parser', externals })
.target('src/compiled/postcss-safe-parser')
2020-03-30 04:01:30 +02:00
}
// eslint-disable-next-line camelcase
externals['postcss-preset-env'] = 'next/dist/compiled/postcss-preset-env'
export async function ncc_postcss_preset_env(task, opts) {
await task
.source(relative(__dirname, require.resolve('postcss-preset-env')))
2020-03-30 04:01:30 +02:00
.ncc({ packageName: 'postcss-preset-env', externals })
.target('src/compiled/postcss-preset-env')
2020-03-30 04:01:30 +02:00
}
// eslint-disable-next-line camelcase
externals['postcss-scss'] = 'next/dist/compiled/postcss-scss'
export async function ncc_postcss_scss(task, opts) {
await task
.source(relative(__dirname, require.resolve('postcss-scss')))
.ncc({
packageName: 'postcss-scss',
externals: {
'postcss/lib/parser': 'postcss/lib/parser',
...externals,
},
})
.target('src/compiled/postcss-scss')
}
// eslint-disable-next-line camelcase
externals['postcss-modules-extract-imports'] =
'next/dist/compiled/postcss-modules-extract-imports'
export async function ncc_postcss_modules_extract_imports(task, opts) {
await task
.source(
relative(__dirname, require.resolve('postcss-modules-extract-imports'))
)
.ncc({
packageName: 'postcss-modules-extract-imports',
externals: {
'postcss/lib/parser': 'postcss/lib/parser',
...externals,
},
})
.target('src/compiled/postcss-modules-extract-imports')
}
// eslint-disable-next-line camelcase
externals['postcss-modules-local-by-default'] =
'next/dist/compiled/postcss-modules-local-by-default'
export async function ncc_postcss_modules_local_by_default(task, opts) {
await task
.source(
relative(__dirname, require.resolve('postcss-modules-local-by-default'))
)
.ncc({
packageName: 'postcss-modules-local-by-default',
externals: {
'postcss/lib/parser': 'postcss/lib/parser',
...externals,
},
})
.target('src/compiled/postcss-modules-local-by-default')
}
// eslint-disable-next-line camelcase
externals['postcss-modules-scope'] = 'next/dist/compiled/postcss-modules-scope'
export async function ncc_postcss_modules_scope(task, opts) {
await task
.source(relative(__dirname, require.resolve('postcss-modules-scope')))
.ncc({
packageName: 'postcss-modules-scope',
externals: {
'postcss/lib/parser': 'postcss/lib/parser',
...externals,
},
})
.target('src/compiled/postcss-modules-scope')
}
// eslint-disable-next-line camelcase
externals['postcss-modules-values'] =
'next/dist/compiled/postcss-modules-values'
export async function ncc_postcss_modules_values(task, opts) {
await task
.source(relative(__dirname, require.resolve('postcss-modules-values')))
.ncc({
packageName: 'postcss-modules-values',
externals: {
'postcss/lib/parser': 'postcss/lib/parser',
...externals,
},
})
.target('src/compiled/postcss-modules-values')
}
// eslint-disable-next-line camelcase
externals['postcss-value-parser'] = 'next/dist/compiled/postcss-value-parser'
export async function ncc_postcss_value_parser(task, opts) {
await task
.source(relative(__dirname, require.resolve('postcss-value-parser')))
.ncc({
packageName: 'postcss-value-parser',
externals: {
'postcss/lib/parser': 'postcss/lib/parser',
...externals,
},
})
.target('src/compiled/postcss-value-parser')
}
// eslint-disable-next-line camelcase
externals['icss-utils'] = 'next/dist/compiled/icss-utils'
export async function ncc_icss_utils(task, opts) {
await task
.source(relative(__dirname, require.resolve('icss-utils')))
.ncc({
packageName: 'icss-utils',
externals: {
'postcss/lib/parser': 'postcss/lib/parser',
...externals,
},
})
.target('src/compiled/icss-utils')
}
externals['scheduler'] = 'next/dist/compiled/scheduler-experimental'
externals['scheduler'] = 'next/dist/compiled/scheduler'
export async function copy_vendor_react(task_) {
function* copy_vendor_react_impl(task, opts) {
const channel = opts.experimental ? `experimental-builtin` : `builtin`
const packageSuffix = opts.experimental ? `-experimental` : ``
// Override the `react`, `react-dom` and `scheduler`'s package names to avoid
// "The name `react` was looked up in the Haste module map" warnings.
// TODO-APP: remove unused fields from package.json and unused files
function overridePackageName(source) {
const json = JSON.parse(source)
json.name = json.name + '-' + channel
return JSON.stringify(
{
name: json.name,
main: json.main,
exports: json.exports,
dependencies: json.dependencies,
peerDependencies: json.peerDependencies,
browser: json.browser,
},
null,
2
)
}
const schedulerDir = dirname(
relative(__dirname, require.resolve(`scheduler-${channel}/package.json`))
)
yield task
.source(join(schedulerDir, '*.{json,js}'))
// eslint-disable-next-line require-yield
.run({ every: true }, function* (file) {
if (file.base === 'package.json') {
file.data = overridePackageName(file.data.toString())
}
})
.target(`src/compiled/scheduler${packageSuffix}`)
yield task
.source(join(schedulerDir, 'cjs/**/*.js'))
.target(`src/compiled/scheduler${packageSuffix}/cjs`)
yield task
.source(join(schedulerDir, 'LICENSE'))
.target(`src/compiled/scheduler${packageSuffix}`)
const reactDir = dirname(
relative(__dirname, require.resolve(`react-${channel}/package.json`))
)
const reactDomDir = dirname(
relative(__dirname, require.resolve(`react-dom-${channel}/package.json`))
)
yield task
.source(join(reactDir, '*.{json,js}'))
// eslint-disable-next-line require-yield
.run({ every: true }, function* (file) {
if (file.base === 'package.json') {
file.data = overridePackageName(file.data.toString())
}
})
.target(`src/compiled/react${packageSuffix}`)
yield task
.source(join(reactDir, 'LICENSE'))
.target(`src/compiled/react${packageSuffix}`)
yield task
.source(join(reactDir, 'cjs/**/*.js'))
// eslint-disable-next-line require-yield
.run({ every: true }, function* (file) {
const source = file.data.toString()
// We replace the module/chunk loading code with our own implementation in Next.js.
file.data = source.replace(
/require\(["']react["']\)/g,
`require("next/dist/compiled/react${packageSuffix}")`
)
})
.target(`src/compiled/react${packageSuffix}/cjs`)
yield task
.source(join(reactDomDir, '*.{json,js}'))
// eslint-disable-next-line require-yield
.run({ every: true }, function* (file) {
if (file.base === 'package.json') {
file.data = overridePackageName(file.data.toString())
}
})
.target(`src/compiled/react-dom${packageSuffix}`)
yield task
.source(join(reactDomDir, 'LICENSE'))
.target(`src/compiled/react-dom${packageSuffix}`)
yield task
.source(join(reactDomDir, 'cjs/**/*.js'))
// eslint-disable-next-line require-yield
.run({ every: true }, function* (file) {
const source = file.data.toString()
// We replace the module/chunk loading code with our own implementation in Next.js.
file.data = source
.replace(
/require\(["']scheduler["']\)/g,
`require("next/dist/compiled/scheduler${packageSuffix}")`
)
.replace(
/require\(["']react["']\)/g,
`require("next/dist/compiled/react${packageSuffix}")`
)
// Note that we don't replace `react-dom` with `next/dist/compiled/react-dom`
// as it mighe be aliased to the server rendering stub.
})
.target(`src/compiled/react-dom${packageSuffix}/cjs`)
// Remove unused files
const reactDomCompiledDir = join(
__dirname,
`src/compiled/react-dom${packageSuffix}`
)
const itemsToRemove = [
'static.js',
'static.node.js',
'static.browser.js',
'unstable_testing.js',
'test-utils.js',
'server.bun.js',
'cjs/react-dom-server.bun.development.js',
'cjs/react-dom-server.bun.production.min.js',
'cjs/react-dom-test-utils.development.js',
'cjs/react-dom-test-utils.production.min.js',
'unstable_server-external-runtime.js',
]
for (const item of itemsToRemove) {
yield rmrf(join(reactDomCompiledDir, item))
}
// react-server-dom-webpack
// Currently, this `next` and `experimental` channels are always in sync so
// we can use the same version for both.
App Router - preinitialize chunks during SSR (#54752) Today when we hydrate an SSR'd RSC response on the client we encounter import chunks which initiate code loading for client components. However we only start fetching these chunks after hydration has begun which is necessarily after the initial chunks for the entrypoint have loaded. React has upstream changes that need to land which will preinitialize the rendered chunks for all client components used during the SSR pass. This will cause a `<script async="" src... />` tag to be emitted in the head for each chunk we need to load during hydration which allows the browser to start fetching these resources even before the entrypoint has started to execute. Additionally the implementation for webpack and turbopack is different enough that there will be a new `react-server-dom-turbopack` package in the React repo which should be used when using Turbopack with Next. This PR also removes a number of patches to React src that proxy loading (`__next_chunk_load__`) and bundler requires (`__next_require__`) through the `globalThis` object. Now the react packages can be fully responsible for implementing chunk loading and all Next needs to do is supply the necessary information such as chunk prefix and crossOrigin attributes necessary for this loading. This information is produced as part of the client-manifest by either a Webpack plugin or Turbopack. Additionally any modifications to the chunk filename that were previously done at runtime need to be made in the manifest itself now. This means we need to encode the deployment id for skew protection and encode the filename to make it match our static path matching (and resolutions on s3) when using `[` and `]` segment characters. There are a few followup items to consider in later PRs 1. we currently bundle a node and edge version of react-server-dom-webpack/client. The node version has an implementation for busboy whereas the edge version does not. Next is currently configured to use busboy when handling a fetch action sent as multipart with a node runtime. Ideally we'd only bundle the one platform we are buliding for but some additional refactoring to support better forking is possibly required here This PR also updates react from 09285d5a7 to d900fadbf. ### React upstream changes - https://github.com/facebook/react/pull/27439 - https://github.com/facebook/react/pull/26763 - https://github.com/facebook/react/pull/27434 - https://github.com/facebook/react/pull/27433 - https://github.com/facebook/react/pull/27424 - https://github.com/facebook/react/pull/27428 - https://github.com/facebook/react/pull/27427 - https://github.com/facebook/react/pull/27315 - https://github.com/facebook/react/pull/27314 - https://github.com/facebook/react/pull/27400 - https://github.com/facebook/react/pull/27421 - https://github.com/facebook/react/pull/27419 - https://github.com/facebook/react/pull/27418
2023-10-03 23:40:25 +02:00
const reactServerDomWebpackDir = dirname(
relative(
__dirname,
require.resolve(`react-server-dom-webpack${packageSuffix}/package.json`)
)
)
yield task
App Router - preinitialize chunks during SSR (#54752) Today when we hydrate an SSR'd RSC response on the client we encounter import chunks which initiate code loading for client components. However we only start fetching these chunks after hydration has begun which is necessarily after the initial chunks for the entrypoint have loaded. React has upstream changes that need to land which will preinitialize the rendered chunks for all client components used during the SSR pass. This will cause a `<script async="" src... />` tag to be emitted in the head for each chunk we need to load during hydration which allows the browser to start fetching these resources even before the entrypoint has started to execute. Additionally the implementation for webpack and turbopack is different enough that there will be a new `react-server-dom-turbopack` package in the React repo which should be used when using Turbopack with Next. This PR also removes a number of patches to React src that proxy loading (`__next_chunk_load__`) and bundler requires (`__next_require__`) through the `globalThis` object. Now the react packages can be fully responsible for implementing chunk loading and all Next needs to do is supply the necessary information such as chunk prefix and crossOrigin attributes necessary for this loading. This information is produced as part of the client-manifest by either a Webpack plugin or Turbopack. Additionally any modifications to the chunk filename that were previously done at runtime need to be made in the manifest itself now. This means we need to encode the deployment id for skew protection and encode the filename to make it match our static path matching (and resolutions on s3) when using `[` and `]` segment characters. There are a few followup items to consider in later PRs 1. we currently bundle a node and edge version of react-server-dom-webpack/client. The node version has an implementation for busboy whereas the edge version does not. Next is currently configured to use busboy when handling a fetch action sent as multipart with a node runtime. Ideally we'd only bundle the one platform we are buliding for but some additional refactoring to support better forking is possibly required here This PR also updates react from 09285d5a7 to d900fadbf. ### React upstream changes - https://github.com/facebook/react/pull/27439 - https://github.com/facebook/react/pull/26763 - https://github.com/facebook/react/pull/27434 - https://github.com/facebook/react/pull/27433 - https://github.com/facebook/react/pull/27424 - https://github.com/facebook/react/pull/27428 - https://github.com/facebook/react/pull/27427 - https://github.com/facebook/react/pull/27315 - https://github.com/facebook/react/pull/27314 - https://github.com/facebook/react/pull/27400 - https://github.com/facebook/react/pull/27421 - https://github.com/facebook/react/pull/27419 - https://github.com/facebook/react/pull/27418
2023-10-03 23:40:25 +02:00
.source(join(reactServerDomWebpackDir, 'LICENSE'))
.target(`src/compiled/react-server-dom-webpack${packageSuffix}`)
yield task
App Router - preinitialize chunks during SSR (#54752) Today when we hydrate an SSR'd RSC response on the client we encounter import chunks which initiate code loading for client components. However we only start fetching these chunks after hydration has begun which is necessarily after the initial chunks for the entrypoint have loaded. React has upstream changes that need to land which will preinitialize the rendered chunks for all client components used during the SSR pass. This will cause a `<script async="" src... />` tag to be emitted in the head for each chunk we need to load during hydration which allows the browser to start fetching these resources even before the entrypoint has started to execute. Additionally the implementation for webpack and turbopack is different enough that there will be a new `react-server-dom-turbopack` package in the React repo which should be used when using Turbopack with Next. This PR also removes a number of patches to React src that proxy loading (`__next_chunk_load__`) and bundler requires (`__next_require__`) through the `globalThis` object. Now the react packages can be fully responsible for implementing chunk loading and all Next needs to do is supply the necessary information such as chunk prefix and crossOrigin attributes necessary for this loading. This information is produced as part of the client-manifest by either a Webpack plugin or Turbopack. Additionally any modifications to the chunk filename that were previously done at runtime need to be made in the manifest itself now. This means we need to encode the deployment id for skew protection and encode the filename to make it match our static path matching (and resolutions on s3) when using `[` and `]` segment characters. There are a few followup items to consider in later PRs 1. we currently bundle a node and edge version of react-server-dom-webpack/client. The node version has an implementation for busboy whereas the edge version does not. Next is currently configured to use busboy when handling a fetch action sent as multipart with a node runtime. Ideally we'd only bundle the one platform we are buliding for but some additional refactoring to support better forking is possibly required here This PR also updates react from 09285d5a7 to d900fadbf. ### React upstream changes - https://github.com/facebook/react/pull/27439 - https://github.com/facebook/react/pull/26763 - https://github.com/facebook/react/pull/27434 - https://github.com/facebook/react/pull/27433 - https://github.com/facebook/react/pull/27424 - https://github.com/facebook/react/pull/27428 - https://github.com/facebook/react/pull/27427 - https://github.com/facebook/react/pull/27315 - https://github.com/facebook/react/pull/27314 - https://github.com/facebook/react/pull/27400 - https://github.com/facebook/react/pull/27421 - https://github.com/facebook/react/pull/27419 - https://github.com/facebook/react/pull/27418
2023-10-03 23:40:25 +02:00
.source(join(reactServerDomWebpackDir, '{package.json,*.js,cjs/**/*.js}'))
// eslint-disable-next-line require-yield
.run({ every: true }, function* (file) {
// We replace the module/chunk loading code with our own implementation in Next.js.
App Router - preinitialize chunks during SSR (#54752) Today when we hydrate an SSR'd RSC response on the client we encounter import chunks which initiate code loading for client components. However we only start fetching these chunks after hydration has begun which is necessarily after the initial chunks for the entrypoint have loaded. React has upstream changes that need to land which will preinitialize the rendered chunks for all client components used during the SSR pass. This will cause a `<script async="" src... />` tag to be emitted in the head for each chunk we need to load during hydration which allows the browser to start fetching these resources even before the entrypoint has started to execute. Additionally the implementation for webpack and turbopack is different enough that there will be a new `react-server-dom-turbopack` package in the React repo which should be used when using Turbopack with Next. This PR also removes a number of patches to React src that proxy loading (`__next_chunk_load__`) and bundler requires (`__next_require__`) through the `globalThis` object. Now the react packages can be fully responsible for implementing chunk loading and all Next needs to do is supply the necessary information such as chunk prefix and crossOrigin attributes necessary for this loading. This information is produced as part of the client-manifest by either a Webpack plugin or Turbopack. Additionally any modifications to the chunk filename that were previously done at runtime need to be made in the manifest itself now. This means we need to encode the deployment id for skew protection and encode the filename to make it match our static path matching (and resolutions on s3) when using `[` and `]` segment characters. There are a few followup items to consider in later PRs 1. we currently bundle a node and edge version of react-server-dom-webpack/client. The node version has an implementation for busboy whereas the edge version does not. Next is currently configured to use busboy when handling a fetch action sent as multipart with a node runtime. Ideally we'd only bundle the one platform we are buliding for but some additional refactoring to support better forking is possibly required here This PR also updates react from 09285d5a7 to d900fadbf. ### React upstream changes - https://github.com/facebook/react/pull/27439 - https://github.com/facebook/react/pull/26763 - https://github.com/facebook/react/pull/27434 - https://github.com/facebook/react/pull/27433 - https://github.com/facebook/react/pull/27424 - https://github.com/facebook/react/pull/27428 - https://github.com/facebook/react/pull/27427 - https://github.com/facebook/react/pull/27315 - https://github.com/facebook/react/pull/27314 - https://github.com/facebook/react/pull/27400 - https://github.com/facebook/react/pull/27421 - https://github.com/facebook/react/pull/27419 - https://github.com/facebook/react/pull/27418
2023-10-03 23:40:25 +02:00
// NOTE: We only replace module/chunk loading for server builds because the server
// bundles have unique constraints like a runtime bundle. For browser builds this
// package will be bundled alongside user code and we don't need to introduce the extra
// indirection
if (
(file.base.startsWith('react-server-dom-webpack-client') &&
!file.base.startsWith('react-server-dom-webpack-client.browser')) ||
(file.base.startsWith('react-server-dom-webpack-server') &&
!file.base.startsWith('react-server-dom-webpack-server.browser'))
) {
const source = file.data.toString()
file.data = source.replace(
/__webpack_require__/g,
'globalThis.__next_require__'
)
} else if (file.base === 'package.json') {
file.data = overridePackageName(file.data)
}
})
.target(`src/compiled/react-server-dom-webpack${packageSuffix}`)
App Router - preinitialize chunks during SSR (#54752) Today when we hydrate an SSR'd RSC response on the client we encounter import chunks which initiate code loading for client components. However we only start fetching these chunks after hydration has begun which is necessarily after the initial chunks for the entrypoint have loaded. React has upstream changes that need to land which will preinitialize the rendered chunks for all client components used during the SSR pass. This will cause a `<script async="" src... />` tag to be emitted in the head for each chunk we need to load during hydration which allows the browser to start fetching these resources even before the entrypoint has started to execute. Additionally the implementation for webpack and turbopack is different enough that there will be a new `react-server-dom-turbopack` package in the React repo which should be used when using Turbopack with Next. This PR also removes a number of patches to React src that proxy loading (`__next_chunk_load__`) and bundler requires (`__next_require__`) through the `globalThis` object. Now the react packages can be fully responsible for implementing chunk loading and all Next needs to do is supply the necessary information such as chunk prefix and crossOrigin attributes necessary for this loading. This information is produced as part of the client-manifest by either a Webpack plugin or Turbopack. Additionally any modifications to the chunk filename that were previously done at runtime need to be made in the manifest itself now. This means we need to encode the deployment id for skew protection and encode the filename to make it match our static path matching (and resolutions on s3) when using `[` and `]` segment characters. There are a few followup items to consider in later PRs 1. we currently bundle a node and edge version of react-server-dom-webpack/client. The node version has an implementation for busboy whereas the edge version does not. Next is currently configured to use busboy when handling a fetch action sent as multipart with a node runtime. Ideally we'd only bundle the one platform we are buliding for but some additional refactoring to support better forking is possibly required here This PR also updates react from 09285d5a7 to d900fadbf. ### React upstream changes - https://github.com/facebook/react/pull/27439 - https://github.com/facebook/react/pull/26763 - https://github.com/facebook/react/pull/27434 - https://github.com/facebook/react/pull/27433 - https://github.com/facebook/react/pull/27424 - https://github.com/facebook/react/pull/27428 - https://github.com/facebook/react/pull/27427 - https://github.com/facebook/react/pull/27315 - https://github.com/facebook/react/pull/27314 - https://github.com/facebook/react/pull/27400 - https://github.com/facebook/react/pull/27421 - https://github.com/facebook/react/pull/27419 - https://github.com/facebook/react/pull/27418
2023-10-03 23:40:25 +02:00
// react-server-dom-turbopack
// Currently, this `next` and `experimental` channels are always in sync so
// we can use the same version for both.
const reactServerDomTurbopackDir = dirname(
relative(
__dirname,
require.resolve(
`react-server-dom-turbopack${packageSuffix}/package.json`
)
)
)
yield task
.source(join(reactServerDomTurbopackDir, 'LICENSE'))
.target(`src/compiled/react-server-dom-turbopack${packageSuffix}`)
yield task
.source(
join(reactServerDomTurbopackDir, '{package.json,*.js,cjs/**/*.js}')
)
// eslint-disable-next-line require-yield
.run({ every: true }, function* (file) {
// We replace the module loading code with our own implementation in Next.js.
// NOTE: We only replace module loading for server builds because the server
// bundles have unique constraints like a runtime bundle. For browser builds this
// package will be bundled alongside user code and we don't need to introduce the extra
// indirection
if (
(file.base.startsWith('react-server-dom-turbopack-client') &&
!file.base.startsWith(
'react-server-dom-turbopack-client.browser'
)) ||
(file.base.startsWith('react-server-dom-turbopack-server') &&
!file.base.startsWith('react-server-dom-turbopack-server.browser'))
) {
const source = file.data.toString()
file.data = source
.replace(/__turbopack_load__/g, 'globalThis.__next_chunk_load__')
.replace(/__turbopack_require__/g, 'globalThis.__next_require__')
} else if (file.base === 'package.json') {
file.data = overridePackageName(file.data)
}
})
.target(`src/compiled/react-server-dom-turbopack${packageSuffix}`)
}
// As taskr transpiles async functions into generators, to reuse the same logic
// we need to directly write this iteration logic here.
for (const res of copy_vendor_react_impl(task_, { experimental: false })) {
await res
}
for (const res of copy_vendor_react_impl(task_, { experimental: true })) {
await res
}
}
// eslint-disable-next-line camelcase
export async function ncc_rsc_poison_packages(task, opts) {
await task
.source(join(dirname(require.resolve('server-only')), '*'))
.target('src/compiled/server-only')
await task
.source(join(dirname(require.resolve('client-only')), '*'))
.target('src/compiled/client-only')
}
externals['sass-loader'] = 'next/dist/compiled/sass-loader'
// eslint-disable-next-line camelcase
export async function ncc_sass_loader(task, opts) {
const sassLoaderPath = require.resolve('sass-loader')
const utilsPath = join(dirname(sassLoaderPath), 'utils.js')
const originalContent = await fs.readFile(utilsPath, 'utf8')
await fs.writeFile(
utilsPath,
originalContent.replace(
/require\.resolve\(["'](sass|node-sass)["']\)/g,
'eval("require").resolve("$1")'
)
)
await task
.source(relative(__dirname, sassLoaderPath))
.ncc({
packageName: 'sass-loader',
externals: {
...externals,
'schema-utils': externals['schema-utils3'],
'loader-utils': externals['loader-utils2'],
},
target: 'es5',
})
.target('src/compiled/sass-loader')
}
// eslint-disable-next-line camelcase
externals['schema-utils'] = 'MISSING_VERSION schema-utils version not specified'
externals['schema-utils2'] = 'next/dist/compiled/schema-utils2'
export async function ncc_schema_utils2(task, opts) {
await task
.source(relative(__dirname, require.resolve('schema-utils2')))
.ncc({
packageName: 'schema-utils',
bundleName: 'schema-utils2',
externals,
})
.target('src/compiled/schema-utils2')
}
// eslint-disable-next-line camelcase
externals['schema-utils3'] = 'next/dist/compiled/schema-utils3'
export async function ncc_schema_utils3(task, opts) {
await task
.source(relative(__dirname, require.resolve('schema-utils3')))
.ncc({
packageName: 'schema-utils',
bundleName: 'schema-utils3',
externals,
})
.target('src/compiled/schema-utils3')
}
externals['semver'] = 'next/dist/compiled/semver'
export async function ncc_semver(task, opts) {
await task
.source(relative(__dirname, require.resolve('semver')))
.ncc({ packageName: 'semver', externals })
.target('src/compiled/semver')
}
// eslint-disable-next-line camelcase
externals['send'] = 'next/dist/compiled/send'
2020-03-29 03:40:29 +02:00
export async function ncc_send(task, opts) {
await task
.source(relative(__dirname, require.resolve('send')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'send', externals })
.target('src/compiled/send')
2020-03-29 03:40:29 +02:00
}
// eslint-disable-next-line camelcase
2020-05-09 17:21:53 +02:00
// NB: Used by other dependencies, but Vercel version is a duplicate
2020-03-29 21:07:55 +02:00
// version so can be inlined anyway (although may change in future)
externals['source-map'] = 'next/dist/compiled/source-map'
2020-03-29 05:41:35 +02:00
export async function ncc_source_map(task, opts) {
await task
.source(relative(__dirname, require.resolve('source-map')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'source-map', externals })
.target('src/compiled/source-map')
2020-03-29 05:41:35 +02:00
}
// eslint-disable-next-line camelcase
externals['string-hash'] = 'next/dist/compiled/string-hash'
2020-03-29 05:05:26 +02:00
export async function ncc_string_hash(task, opts) {
await task
.source(relative(__dirname, require.resolve('string-hash')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'string-hash', externals })
.target('src/compiled/string-hash')
2020-03-29 05:05:26 +02:00
}
// eslint-disable-next-line camelcase
externals['strip-ansi'] = 'next/dist/compiled/strip-ansi'
2020-03-29 05:05:26 +02:00
export async function ncc_strip_ansi(task, opts) {
await task
.source(relative(__dirname, require.resolve('strip-ansi')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'strip-ansi', externals })
.target('src/compiled/strip-ansi')
2020-03-29 05:05:26 +02:00
}
// eslint-disable-next-line camelcase
externals['@vercel/nft'] = 'next/dist/compiled/@vercel/nft'
export async function ncc_nft(task, opts) {
await task
.source(relative(__dirname, require.resolve('@vercel/nft')))
.ncc({ packageName: '@vercel/nft', externals })
.target('src/compiled/@vercel/nft')
}
// eslint-disable-next-line camelcase
externals['tar'] = 'next/dist/compiled/tar'
export async function ncc_tar(task, opts) {
await task
.source(relative(__dirname, require.resolve('tar')))
.ncc({ packageName: 'tar', externals })
.target('src/compiled/tar')
}
// eslint-disable-next-line camelcase
externals['terser'] = 'next/dist/compiled/terser'
2020-03-29 05:52:40 +02:00
export async function ncc_terser(task, opts) {
await task
.source(relative(__dirname, require.resolve('terser')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'terser', externals })
.target('src/compiled/terser')
2020-03-29 05:52:40 +02:00
}
// eslint-disable-next-line camelcase
externals['text-table'] = 'next/dist/compiled/text-table'
export async function ncc_text_table(task, opts) {
await task
.source(relative(__dirname, require.resolve('text-table')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'text-table', externals })
.target('src/compiled/text-table')
}
// eslint-disable-next-line camelcase
externals['unistore'] = 'next/dist/compiled/unistore'
export async function ncc_unistore(task, opts) {
await task
.source(relative(__dirname, require.resolve('unistore')))
2020-03-29 18:16:32 +02:00
.ncc({ packageName: 'unistore', externals })
.target('src/compiled/unistore')
}
perf: replace zod with superstruct (#56083) This PR replaces the usage of Zod in the App Router in favour of a smaller validation library. We don't use much of zod's more advanced capabilities so it doesn't make sense to import all of it on the server at the moment. Also added some unit tests. This results in a 44kb win, which will impact cold boot Before: <img width="594" alt="CleanShot 2023-09-27 at 13 34 09@2x" src="https://github.com/vercel/next.js/assets/11064311/43cc7687-947d-40a1-9e1e-c2a60caf53c0"> After: <img width="564" alt="CleanShot 2023-09-27 at 13 34 48@2x" src="https://github.com/vercel/next.js/assets/11064311/c3d3f5d6-e1f6-4969-bd11-dcd191d34ce6"> <!-- 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(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
2023-09-28 11:05:36 +02:00
// eslint-disable-next-line camelcase
refactor: rewrite config schema in zod (#56383) The PR supersedes the https://github.com/vercel/next.js/pull/53150, which is way too outdated, has way too many conflicts, and also heavily relies on GitHub Copilot (which makes the progress slow and tedious). The PR uses [`json-schema-to-zod`](https://github.com/StefanTerdell/json-schema-to-zod) (instead of the GitHub Copilot) to generate the zod schema, and manually replaces all generated `z.customRefine` with my hand-written zod schema. TODO: - [x] Convert schema - [x] Reduce `z.any()` usage - [x] Create human-readable errors from the `ZodError` - [x] Update test cases to reflect the latest error message ----- The benefit of using zod over ajv: - Easier maintenance: zod schema is straightforward to compose. - Better typescript support: config schema now strictly reflects the `NextConfig` type. - Smaller installation size: by replacing `ajv` and `@segment/ajv-human-errors` w/ `zod`, I am able to reduce installation size by 114 KiB. - Better Extension: the zod error message is easy to customize. ----- In the previous PR https://github.com/vercel/next.js/pull/56083, @feedthejim replaces `zod` w/ `superstruct`. `superstruct` is lightweight and fast, which makes it perfect for creating simple schemas for RSC payload. But, this also means `superstruct` has its limitations compared to `zod`: - `superstruct`'s syntax is different, and some utilities's usage is counter-intuitive: - `z.array(z.string()).gt(1)` vs `s.size(s.array(s.string()), 1)` - `z.numer().gt(1)` vs `s.size(s.number(), 1)`, `s.min(s.number(), 1)` - `z.boolean().optional().nullable()` vs `s.nullable(s.optional(z.boolean()))` - `superstruct` has weaker TypeScript support and worse DX compared to `zod` when composing huge schema: - `zod.ZodType + z.object()` can provide a more detailed type mismatch message on which specific property is the culprit, while `Describe + s.object()` provides almost no information at all. - `zod`'s schema is more powerful - `z.function()` supports `z.args()` and `z.returns()`, while `superstruct` only has `s.func()` - zod also has Promise type `z.promise()` and intersection type `z.and()` - `superstruct`'s error is harder to parse compared to `zod`'s `ZodError` So in the PR, I re-introduced `zod` for `next.config.js` validation.
2023-10-05 17:46:53 +02:00
externals['superstruct'] = 'next/dist/compiled/superstruct'
perf: replace zod with superstruct (#56083) This PR replaces the usage of Zod in the App Router in favour of a smaller validation library. We don't use much of zod's more advanced capabilities so it doesn't make sense to import all of it on the server at the moment. Also added some unit tests. This results in a 44kb win, which will impact cold boot Before: <img width="594" alt="CleanShot 2023-09-27 at 13 34 09@2x" src="https://github.com/vercel/next.js/assets/11064311/43cc7687-947d-40a1-9e1e-c2a60caf53c0"> After: <img width="564" alt="CleanShot 2023-09-27 at 13 34 48@2x" src="https://github.com/vercel/next.js/assets/11064311/c3d3f5d6-e1f6-4969-bd11-dcd191d34ce6"> <!-- 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(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
2023-09-28 11:05:36 +02:00
export async function ncc_superstruct(task, opts) {
await task
.source(relative(__dirname, require.resolve('superstruct')))
.ncc({ packageName: 'superstruct', externals })
.target('src/compiled/superstruct')
}
refactor: rewrite config schema in zod (#56383) The PR supersedes the https://github.com/vercel/next.js/pull/53150, which is way too outdated, has way too many conflicts, and also heavily relies on GitHub Copilot (which makes the progress slow and tedious). The PR uses [`json-schema-to-zod`](https://github.com/StefanTerdell/json-schema-to-zod) (instead of the GitHub Copilot) to generate the zod schema, and manually replaces all generated `z.customRefine` with my hand-written zod schema. TODO: - [x] Convert schema - [x] Reduce `z.any()` usage - [x] Create human-readable errors from the `ZodError` - [x] Update test cases to reflect the latest error message ----- The benefit of using zod over ajv: - Easier maintenance: zod schema is straightforward to compose. - Better typescript support: config schema now strictly reflects the `NextConfig` type. - Smaller installation size: by replacing `ajv` and `@segment/ajv-human-errors` w/ `zod`, I am able to reduce installation size by 114 KiB. - Better Extension: the zod error message is easy to customize. ----- In the previous PR https://github.com/vercel/next.js/pull/56083, @feedthejim replaces `zod` w/ `superstruct`. `superstruct` is lightweight and fast, which makes it perfect for creating simple schemas for RSC payload. But, this also means `superstruct` has its limitations compared to `zod`: - `superstruct`'s syntax is different, and some utilities's usage is counter-intuitive: - `z.array(z.string()).gt(1)` vs `s.size(s.array(s.string()), 1)` - `z.numer().gt(1)` vs `s.size(s.number(), 1)`, `s.min(s.number(), 1)` - `z.boolean().optional().nullable()` vs `s.nullable(s.optional(z.boolean()))` - `superstruct` has weaker TypeScript support and worse DX compared to `zod` when composing huge schema: - `zod.ZodType + z.object()` can provide a more detailed type mismatch message on which specific property is the culprit, while `Describe + s.object()` provides almost no information at all. - `zod`'s schema is more powerful - `z.function()` supports `z.args()` and `z.returns()`, while `superstruct` only has `s.func()` - zod also has Promise type `z.promise()` and intersection type `z.and()` - `superstruct`'s error is harder to parse compared to `zod`'s `ZodError` So in the PR, I re-introduced `zod` for `next.config.js` validation.
2023-10-05 17:46:53 +02:00
externals['zod'] = 'next/dist/compiled/zod'
export async function ncc_zod(task, opts) {
await task
.source(relative(__dirname, require.resolve('zod')))
.ncc({ packageName: 'zod', externals })
.target('src/compiled/zod')
}
// eslint-disable-next-line camelcase
externals['web-vitals'] = 'next/dist/compiled/web-vitals'
export async function ncc_web_vitals(task, opts) {
await task
.source(
relative(
__dirname,
resolve(resolveFrom(__dirname, 'web-vitals'), '../web-vitals.js')
)
)
// web-vitals@3.0.0 is pure ESM, compile to CJS for pre-compiled
.ncc({ packageName: 'web-vitals', externals, target: 'es5', esm: false })
.target('src/compiled/web-vitals')
}
// eslint-disable-next-line camelcase
add attribution to web vitals (#39368) This commit implements the main proposal presented in https://github.com/vercel/next.js/issues/39241 to add attribution to web vitals. Attribution adds more specific debugging info to web vitals, for example in the case of Cumulative Layout Shift (CLS), we might want to know > What's the first element that shifted when the single largest layout shift occurred? on in the case of Largest Contentful Paint (LCP), > What's the element corresponding to the LCP for the page? > If it is an image, what's the URL of the image resource? Attribution is *disabled* by default because it could potentially generate a lot data and overwhelm the RUM backend. It is enabled *per metric* (LCP, FCP, CLS, etc) As part of this change, `web-vitals` has been upgraded to v3.0.0 This version contains minor bug fixes, please see changelog at https://github.com/GoogleChrome/web-vitals/commit/9fe3cc02c875cb70ac0f1803f5e11b428e7a4014 Fixes #39241 ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` ## Feature - [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. - [x] Related issues linked using `fixes #number` - [x] Integration tests added - [x] 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` - [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: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-10-04 02:17:30 +02:00
externals['web-vitals-attribution'] =
'next/dist/compiled/web-vitals-attribution'
export async function ncc_web_vitals_attribution(task, opts) {
await task
.source(
relative(
__dirname,
resolve(require.resolve('web-vitals'), '../web-vitals.attribution.js')
)
add attribution to web vitals (#39368) This commit implements the main proposal presented in https://github.com/vercel/next.js/issues/39241 to add attribution to web vitals. Attribution adds more specific debugging info to web vitals, for example in the case of Cumulative Layout Shift (CLS), we might want to know > What's the first element that shifted when the single largest layout shift occurred? on in the case of Largest Contentful Paint (LCP), > What's the element corresponding to the LCP for the page? > If it is an image, what's the URL of the image resource? Attribution is *disabled* by default because it could potentially generate a lot data and overwhelm the RUM backend. It is enabled *per metric* (LCP, FCP, CLS, etc) As part of this change, `web-vitals` has been upgraded to v3.0.0 This version contains minor bug fixes, please see changelog at https://github.com/GoogleChrome/web-vitals/commit/9fe3cc02c875cb70ac0f1803f5e11b428e7a4014 Fixes #39241 ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` ## Feature - [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. - [x] Related issues linked using `fixes #number` - [x] Integration tests added - [x] 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` - [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: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-10-04 02:17:30 +02:00
)
.ncc({
packageName: 'web-vitals',
bundleName: 'web-vitals-attribution',
externals,
target: 'es5',
esm: false,
})
.target('src/compiled/web-vitals-attribution')
add attribution to web vitals (#39368) This commit implements the main proposal presented in https://github.com/vercel/next.js/issues/39241 to add attribution to web vitals. Attribution adds more specific debugging info to web vitals, for example in the case of Cumulative Layout Shift (CLS), we might want to know > What's the first element that shifted when the single largest layout shift occurred? on in the case of Largest Contentful Paint (LCP), > What's the element corresponding to the LCP for the page? > If it is an image, what's the URL of the image resource? Attribution is *disabled* by default because it could potentially generate a lot data and overwhelm the RUM backend. It is enabled *per metric* (LCP, FCP, CLS, etc) As part of this change, `web-vitals` has been upgraded to v3.0.0 This version contains minor bug fixes, please see changelog at https://github.com/GoogleChrome/web-vitals/commit/9fe3cc02c875cb70ac0f1803f5e11b428e7a4014 Fixes #39241 ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` ## Feature - [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. - [x] Related issues linked using `fixes #number` - [x] Integration tests added - [x] 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` - [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: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-10-04 02:17:30 +02:00
}
// eslint-disable-next-line camelcase
externals['webpack-sources'] = 'error webpack-sources version not specified'
externals['webpack-sources1'] = 'next/dist/compiled/webpack-sources1'
export async function ncc_webpack_sources1(task, opts) {
await task
.source(relative(__dirname, require.resolve('webpack-sources1')))
.ncc({ packageName: 'webpack-sources1', externals, target: 'es5' })
.target('src/compiled/webpack-sources1')
}
// eslint-disable-next-line camelcase
externals['webpack-sources3'] = 'next/dist/compiled/webpack-sources3'
export async function ncc_webpack_sources3(task, opts) {
await task
.source(relative(__dirname, require.resolve('webpack-sources3')))
.ncc({ packageName: 'webpack-sources3', externals, target: 'es5' })
.target('src/compiled/webpack-sources3')
}
// eslint-disable-next-line camelcase
externals['micromatch'] = 'next/dist/compiled/micromatch'
export async function ncc_minimatch(task, opts) {
await task
.source(relative(__dirname, require.resolve('micromatch')))
.ncc({ packageName: 'micromatch', externals })
.target('src/compiled/micromatch')
}
// eslint-disable-next-line camelcase
externals['mini-css-extract-plugin'] =
'next/dist/compiled/mini-css-extract-plugin'
export async function ncc_mini_css_extract_plugin(task, opts) {
await task
.source(
relative(
__dirname,
resolve(require.resolve('mini-css-extract-plugin'), '../index.js')
)
)
.ncc({
externals: {
...externals,
'./index': './index.js',
'schema-utils': externals['schema-utils3'],
'webpack-sources': externals['webpack-sources1'],
},
})
.target('src/compiled/mini-css-extract-plugin')
await task
.source(
relative(
__dirname,
resolve(
require.resolve('mini-css-extract-plugin'),
'../hmr/hotModuleReplacement.js'
)
)
)
.ncc({
externals: {
...externals,
'./hmr': './hmr',
'schema-utils': 'next/dist/compiled/schema-utils3',
},
})
.target('src/compiled/mini-css-extract-plugin/hmr')
await task
.source(relative(__dirname, require.resolve('mini-css-extract-plugin')))
.ncc({
packageName: 'mini-css-extract-plugin',
externals: {
...externals,
'./index': './index.js',
'schema-utils': externals['schema-utils3'],
},
})
.target('src/compiled/mini-css-extract-plugin')
}
// eslint-disable-next-line camelcase
externals['ua-parser-js'] = 'next/dist/compiled/ua-parser-js'
export async function ncc_ua_parser_js(task, opts) {
await task
.source(relative(__dirname, require.resolve('ua-parser-js')))
.ncc({ packageName: 'ua-parser-js', externals })
.target('src/compiled/ua-parser-js')
}
// eslint-disable-next-line camelcase
export async function ncc_webpack_bundle5(task, opts) {
const bundleExternals = {
...externals,
'schema-utils': externals['schema-utils3'],
'webpack-sources': externals['webpack-sources3'],
}
for (const pkg of Object.keys(webpackBundlePackages)) {
delete bundleExternals[pkg]
}
await task
.source('src/bundles/webpack/bundle5.js')
.ncc({
packageName: 'webpack',
bundleName: 'webpack',
customEmit(path) {
if (path.endsWith('.runtime.js')) return `'./${basename(path)}'`
},
externals: bundleExternals,
target: 'es5',
})
.target('src/compiled/webpack')
}
const webpackBundlePackages = {
webpack: 'next/dist/compiled/webpack/webpack-lib',
'webpack/lib/NormalModule': 'next/dist/compiled/webpack/NormalModule',
'webpack/lib/node/NodeTargetPlugin':
'next/dist/compiled/webpack/NodeTargetPlugin',
}
Object.assign(externals, webpackBundlePackages)
export async function ncc_webpack_bundle_packages(task, opts) {
await task
.source('src/bundles/webpack/packages/*')
.target('src/compiled/webpack/')
}
// eslint-disable-next-line camelcase
externals['ws'] = 'next/dist/compiled/ws'
export async function ncc_ws(task, opts) {
await task
.source(relative(__dirname, require.resolve('ws')))
.ncc({ packageName: 'ws', externals })
.target('src/compiled/ws')
}
externals['path-to-regexp'] = 'next/dist/compiled/path-to-regexp'
2020-03-29 19:17:06 +02:00
export async function path_to_regexp(task, opts) {
await task
.source(relative(__dirname, require.resolve('path-to-regexp')))
2020-03-29 19:17:06 +02:00
.target('dist/compiled/path-to-regexp')
}
2020-03-29 19:31:43 +02:00
feat: add OTEL instrumentation for next-server + OTEL example (#46198) fixes NEXT-479 ## content This PR adds a `getTracer` API to Next.js that uses the `otel/api` under the hood to provide Next.js level instrumentation through Open Telemetry. This also adds an example `with-opentelemetry` to demonstrate how it can be used, assuming you have a collector. This allows most notably to have `getServerSideProps` and `fetch` calls inside Server Components traced. ## details - we hide most internals spans, if you want to see all of them, use the NEXT_OTEL_VERBOSE=1 env var - if you want to use this, you'll need to rely on the `config.experimental.instrumentationHook` config option to initialise OTEL, like in the example ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/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` - [ ] [e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md) ## Documentation / Examples - [ ] Make sure the linting passes by running `pnpm build && pnpm lint` - [ ] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
2023-02-22 16:08:22 +01:00
// eslint-disable-next-line camelcase
externals['@opentelemetry/api'] = 'next/dist/compiled/@opentelemetry/api'
export async function ncc_opentelemetry_api(task, opts) {
await task
.source(
opts.src || relative(__dirname, require.resolve('@opentelemetry/api'))
)
.ncc({ packageName: '@opentelemetry/api', externals })
.target('src/compiled/@opentelemetry/api')
}
// eslint-disable-next-line camelcase
externals['http-proxy-agent'] = 'next/dist/compiled/http-proxy-agent'
export async function ncc_http_proxy_agent(task, opts) {
await task
.source(relative(__dirname, require.resolve('http-proxy-agent')))
.ncc({ packageName: 'http-proxy-agent', externals })
.target('src/compiled/http-proxy-agent')
}
// eslint-disable-next-line camelcase
externals['https-proxy-agent'] = 'next/dist/compiled/https-proxy-agent'
export async function ncc_https_proxy_agent(task, opts) {
await task
.source(relative(__dirname, require.resolve('https-proxy-agent')))
.ncc({ packageName: 'https-proxy-agent', externals })
.target('src/compiled/https-proxy-agent')
}
export async function precompile(task, opts) {
await task.parallel(
[
'browser_polyfills',
'path_to_regexp',
'copy_ncced',
'copy_styled_jsx_assets',
],
opts
)
}
// eslint-disable-next-line camelcase
export async function copy_ncced(task) {
// we don't ncc every time we build since these won't change
// that often and can be committed to the repo saving build time
await task.source('src/compiled/**/*').target('dist/compiled')
}
export async function ncc(task, opts) {
await task
.clear('compiled')
.parallel(
[
'ncc_node_html_parser',
'ncc_napirs_triples',
'ncc_p_limit',
'ncc_raw_body',
'ncc_image_size',
'ncc_get_orientation',
'ncc_hapi_accept',
'ncc_node_fetch',
'ncc_node_anser',
'ncc_node_stacktrace_parser',
'ncc_node_data_uri_to_buffer',
'ncc_node_cssescape',
'ncc_node_platform',
'ncc_node_shell_quote',
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
'ncc_undici',
'ncc_acorn',
'ncc_amphtml_validator',
'ncc_arg',
'ncc_async_retry',
'ncc_async_sema',
'ncc_postcss_plugin_stub_for_cssnano_simple',
'ncc_assert',
'ncc_browser_zlib',
'ncc_buffer',
'ncc_crypto_browserify',
'ncc_domain_browser',
'ncc_events',
'ncc_stream_browserify',
'ncc_stream_http',
'ncc_https_browserify',
'ncc_os_browserify',
'ncc_path_browserify',
'ncc_process',
'ncc_querystring_es3',
'ncc_string_decoder',
'ncc_util',
'ncc_punycode',
'ncc_set_immediate',
'ncc_timers_browserify',
'ncc_tty_browserify',
'ncc_vm_browserify',
'ncc_babel_bundle',
'ncc_bytes',
'ncc_ci_info',
[ESLint] Introduce a new setup process when `next lint` is run for the first time (#26584) This PR introduces an improved developer experience when `next lint` is run for the first time. ### Current behavior `eslint-config-next` is a required package that must be installed before proceeding with `next lint` or `next build`: ![image](https://user-images.githubusercontent.com/12476932/123468791-43088100-d5c0-11eb-9ad0-5beb80b6c968.png) Although this has helped many developers start using the new ESLint config, this has also resulted in a few issues: - Users are required to install the full config (`eslint-config-next`) even if they do not use it or use the Next.js plugin directly (`eslint-plugin-next`). - #26348 - There's some confusion on why `eslint-config-next` needs to be installed or how it should be used instead of `eslint-plugin-next`. - #26574 - #26475 - #26438 ### New behavior Instead of enforcing `eslint-config-next` as a required package, this PR prompts the user by asking what config they would like to start. This happens when `next lint` is run for the first time **and** if no ESLint configuration is detected in the application. <img src="https://user-images.githubusercontent.com/12476932/124331177-e1668a80-db5c-11eb-8915-38d3dc20f5d4.gif" width="800" /> - The CLI will take care of installing `eslint` or `eslint-config-next` if either is not already installed - Users now have the option to choose between a strict configuration (`next/core-web-vitals`) or just the base configuration (`next`) - For users that decide to create their own ESLint configuration, or already have an existing one, **installing `eslint-config-next` will not be a requirement for `next lint` or `next build` to run**. A warning message will just show if the Next.js ESLint plugin is not detected in an ESLint config. <img width="682" alt="Screen Shot 2021-06-25 at 3 02 12 PM" src="https://user-images.githubusercontent.com/12476932/123473329-6cc4a680-d5c6-11eb-9a57-d5c0b89a2732.png"> --- In addition, this PR also: - Fixes #26348 - Updates documentation to make it more clear what approach to take for new and existing ESLint configurations
2021-08-04 23:53:15 +02:00
'ncc_cli_select',
'ncc_comment_json',
'ncc_compression',
'ncc_conf',
'ncc_content_disposition',
'ncc_content_type',
'ncc_cookie',
[ESLint] Introduce a new setup process when `next lint` is run for the first time (#26584) This PR introduces an improved developer experience when `next lint` is run for the first time. ### Current behavior `eslint-config-next` is a required package that must be installed before proceeding with `next lint` or `next build`: ![image](https://user-images.githubusercontent.com/12476932/123468791-43088100-d5c0-11eb-9ad0-5beb80b6c968.png) Although this has helped many developers start using the new ESLint config, this has also resulted in a few issues: - Users are required to install the full config (`eslint-config-next`) even if they do not use it or use the Next.js plugin directly (`eslint-plugin-next`). - #26348 - There's some confusion on why `eslint-config-next` needs to be installed or how it should be used instead of `eslint-plugin-next`. - #26574 - #26475 - #26438 ### New behavior Instead of enforcing `eslint-config-next` as a required package, this PR prompts the user by asking what config they would like to start. This happens when `next lint` is run for the first time **and** if no ESLint configuration is detected in the application. <img src="https://user-images.githubusercontent.com/12476932/124331177-e1668a80-db5c-11eb-8915-38d3dc20f5d4.gif" width="800" /> - The CLI will take care of installing `eslint` or `eslint-config-next` if either is not already installed - Users now have the option to choose between a strict configuration (`next/core-web-vitals`) or just the base configuration (`next`) - For users that decide to create their own ESLint configuration, or already have an existing one, **installing `eslint-config-next` will not be a requirement for `next lint` or `next build` to run**. A warning message will just show if the Next.js ESLint plugin is not detected in an ESLint config. <img width="682" alt="Screen Shot 2021-06-25 at 3 02 12 PM" src="https://user-images.githubusercontent.com/12476932/123473329-6cc4a680-d5c6-11eb-9a57-d5c0b89a2732.png"> --- In addition, this PR also: - Fixes #26348 - Updates documentation to make it more clear what approach to take for new and existing ESLint configurations
2021-08-04 23:53:15 +02:00
'ncc_cross_spawn',
'ncc_debug',
'ncc_devalue',
'ncc_find_cache_dir',
'ncc_find_up',
'ncc_fresh',
'ncc_glob',
'ncc_gzip_size',
'ncc_http_proxy',
'ncc_ignore_loader',
'ncc_is_animated',
'ncc_is_docker',
'ncc_is_wsl',
'ncc_json5',
'ncc_jsonwebtoken',
Add `loader-runner` to compiled packages (#45962) This adds `loader-runner` to the compiled packages distributed with Next.js This is a dependency of Turbopack's webpack loader support. Currently, users have to manually install `loader-runner` in their application to use webpack loaders with Turbopack. This will allow Turbopack to require loader-runner from within the installed version of Next.js instead. Test Plan: `require('./packages/next/dist/compiled/loader-runner/')` <!-- 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(s) that you're making: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/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` - [ ] [e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md) ## Documentation / Examples - [ ] Make sure the linting passes by running `pnpm build && pnpm lint` - [ ] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md) --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>
2023-02-18 07:24:40 +01:00
'ncc_loader_runner',
'ncc_loader_utils2',
'ncc_loader_utils3',
'ncc_lodash_curry',
'ncc_lru_cache',
'ncc_nanoid',
'ncc_native_url',
'ncc_neo_async',
'ncc_ora',
'ncc_postcss_safe_parser',
'ncc_postcss_flexbugs_fixes',
'ncc_postcss_preset_env',
'ncc_postcss_scss',
'ncc_postcss_modules_extract_imports',
'ncc_postcss_modules_local_by_default',
'ncc_postcss_modules_scope',
'ncc_postcss_modules_values',
'ncc_postcss_value_parser',
'ncc_icss_utils',
'ncc_schema_utils2',
'ncc_schema_utils3',
'ncc_semver',
'ncc_send',
'ncc_source_map',
'ncc_string_hash',
'ncc_strip_ansi',
perf: replace zod with superstruct (#56083) This PR replaces the usage of Zod in the App Router in favour of a smaller validation library. We don't use much of zod's more advanced capabilities so it doesn't make sense to import all of it on the server at the moment. Also added some unit tests. This results in a 44kb win, which will impact cold boot Before: <img width="594" alt="CleanShot 2023-09-27 at 13 34 09@2x" src="https://github.com/vercel/next.js/assets/11064311/43cc7687-947d-40a1-9e1e-c2a60caf53c0"> After: <img width="564" alt="CleanShot 2023-09-27 at 13 34 48@2x" src="https://github.com/vercel/next.js/assets/11064311/c3d3f5d6-e1f6-4969-bd11-dcd191d34ce6"> <!-- 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(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
2023-09-28 11:05:36 +02:00
'ncc_superstruct',
refactor: rewrite config schema in zod (#56383) The PR supersedes the https://github.com/vercel/next.js/pull/53150, which is way too outdated, has way too many conflicts, and also heavily relies on GitHub Copilot (which makes the progress slow and tedious). The PR uses [`json-schema-to-zod`](https://github.com/StefanTerdell/json-schema-to-zod) (instead of the GitHub Copilot) to generate the zod schema, and manually replaces all generated `z.customRefine` with my hand-written zod schema. TODO: - [x] Convert schema - [x] Reduce `z.any()` usage - [x] Create human-readable errors from the `ZodError` - [x] Update test cases to reflect the latest error message ----- The benefit of using zod over ajv: - Easier maintenance: zod schema is straightforward to compose. - Better typescript support: config schema now strictly reflects the `NextConfig` type. - Smaller installation size: by replacing `ajv` and `@segment/ajv-human-errors` w/ `zod`, I am able to reduce installation size by 114 KiB. - Better Extension: the zod error message is easy to customize. ----- In the previous PR https://github.com/vercel/next.js/pull/56083, @feedthejim replaces `zod` w/ `superstruct`. `superstruct` is lightweight and fast, which makes it perfect for creating simple schemas for RSC payload. But, this also means `superstruct` has its limitations compared to `zod`: - `superstruct`'s syntax is different, and some utilities's usage is counter-intuitive: - `z.array(z.string()).gt(1)` vs `s.size(s.array(s.string()), 1)` - `z.numer().gt(1)` vs `s.size(s.number(), 1)`, `s.min(s.number(), 1)` - `z.boolean().optional().nullable()` vs `s.nullable(s.optional(z.boolean()))` - `superstruct` has weaker TypeScript support and worse DX compared to `zod` when composing huge schema: - `zod.ZodType + z.object()` can provide a more detailed type mismatch message on which specific property is the culprit, while `Describe + s.object()` provides almost no information at all. - `zod`'s schema is more powerful - `z.function()` supports `z.args()` and `z.returns()`, while `superstruct` only has `s.func()` - zod also has Promise type `z.promise()` and intersection type `z.and()` - `superstruct`'s error is harder to parse compared to `zod`'s `ZodError` So in the PR, I re-introduced `zod` for `next.config.js` validation.
2023-10-05 17:46:53 +02:00
'ncc_zod',
'ncc_nft',
'ncc_tar',
'ncc_terser',
'ncc_text_table',
'ncc_unistore',
'ncc_web_vitals',
add attribution to web vitals (#39368) This commit implements the main proposal presented in https://github.com/vercel/next.js/issues/39241 to add attribution to web vitals. Attribution adds more specific debugging info to web vitals, for example in the case of Cumulative Layout Shift (CLS), we might want to know > What's the first element that shifted when the single largest layout shift occurred? on in the case of Largest Contentful Paint (LCP), > What's the element corresponding to the LCP for the page? > If it is an image, what's the URL of the image resource? Attribution is *disabled* by default because it could potentially generate a lot data and overwhelm the RUM backend. It is enabled *per metric* (LCP, FCP, CLS, etc) As part of this change, `web-vitals` has been upgraded to v3.0.0 This version contains minor bug fixes, please see changelog at https://github.com/GoogleChrome/web-vitals/commit/9fe3cc02c875cb70ac0f1803f5e11b428e7a4014 Fixes #39241 ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` ## Feature - [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. - [x] Related issues linked using `fixes #number` - [x] Integration tests added - [x] 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` - [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: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2022-10-04 02:17:30 +02:00
'ncc_web_vitals_attribution',
'ncc_webpack_bundle5',
'ncc_webpack_sources1',
'ncc_webpack_sources3',
'ncc_ws',
'ncc_ua_parser_js',
'ncc_minimatch',
feat: add OTEL instrumentation for next-server + OTEL example (#46198) fixes NEXT-479 ## content This PR adds a `getTracer` API to Next.js that uses the `otel/api` under the hood to provide Next.js level instrumentation through Open Telemetry. This also adds an example `with-opentelemetry` to demonstrate how it can be used, assuming you have a collector. This allows most notably to have `getServerSideProps` and `fetch` calls inside Server Components traced. ## details - we hide most internals spans, if you want to see all of them, use the NEXT_OTEL_VERBOSE=1 env var - if you want to use this, you'll need to rely on the `config.experimental.instrumentationHook` config option to initialise OTEL, like in the example ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/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` - [ ] [e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md) ## Documentation / Examples - [ ] Make sure the linting passes by running `pnpm build && pnpm lint` - [ ] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
2023-02-22 16:08:22 +01:00
'ncc_opentelemetry_api',
'ncc_http_proxy_agent',
'ncc_https_proxy_agent',
'ncc_mini_css_extract_plugin',
],
opts
)
await task.parallel(['ncc_webpack_bundle_packages'], opts)
await task.parallel(['ncc_babel_bundle_packages'], opts)
await task.serial(
[
'ncc_browserslist',
'ncc_cssnano_simple_bundle',
'copy_regenerator_runtime',
'copy_babel_runtime',
'copy_vercel_og',
'copy_constants_browserify',
'copy_vendor_react',
'copy_react_is',
'ncc_sass_loader',
'ncc_jest_worker',
'ncc_edge_runtime_cookies',
'ncc_edge_runtime_primitives',
'ncc_edge_runtime_ponyfill',
'ncc_edge_runtime',
'ncc_mswjs_interceptors',
],
opts
)
}
export async function next_compile(task, opts) {
await task.parallel(
[
'cli',
'bin',
'server',
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
'server_esm',
'nextbuild',
'nextbuildjest',
'nextbuildstatic',
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
'nextbuild_esm',
'pages',
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
'pages_esm',
'lib',
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
'lib_esm',
'client',
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
'client_esm',
'telemetry',
'trace',
'shared',
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
'shared_esm',
'shared_re_exported',
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
'shared_re_exported_esm',
'server_wasm',
'experimental_testmode',
// we compile this each time so that fresh runtime data is pulled
// before each publish
'ncc_amp_optimizer',
],
opts
)
}
export async function compile(task, opts) {
await task.serial(['next_compile', 'next_bundle'], opts)
await task.serial([
'ncc_react_refresh_utils',
'ncc_next__react_dev_overlay',
Add next/font import (#45891) Enables using `next/font` by adding `@next/font` as a dependency and reexporting its loaders. Always generates the `font-loader-manifest` as we can't know beforehand if the user intends to use `next/font` or not. Also adds telemetry for `next/font` usage. The tests are updated to use `next/font`. But `@next/font` is tested in `test/e2e/next-font/index.test.ts` and `test/e2e/app-dir/next-font` as well to ensure it doesn't break. Fixes NEXT-351 ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/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` - [ ] [e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md) ## Documentation / Examples - [ ] Make sure the linting passes by running `pnpm build && pnpm lint` - [ ] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
2023-02-16 15:33:39 +01:00
'ncc_next_font',
Integrating capsize latest (#47428) Integrating capsize latest <!-- 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(s) that you're making: ## For Contributors ### Improving Documentation or adding/fixing Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>
2023-03-27 05:29:28 +02:00
'capsize_metrics',
])
}
export async function bin(task, opts) {
await task
.source('src/bin/*')
.swc('server', { stripExtension: true, dev: opts.dev })
.target('dist/bin', { mode: '0755' })
}
export async function cli(task, opts) {
await task
.source('src/cli/**/*.+(js|ts|tsx)')
.swc('server', { dev: opts.dev })
.target('dist/cli')
2019-02-26 21:57:32 +01:00
}
export async function lib(task, opts) {
await task
.source('src/lib/**/!(*.test).+(js|ts|tsx|json)')
.swc('server', { dev: opts.dev })
.target('dist/lib')
}
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
export async function lib_esm(task, opts) {
await task
.source('src/lib/**/!(*.test).+(js|ts|tsx|json)')
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
.swc('server', { dev: opts.dev, esm: true })
.target('dist/esm/lib')
}
export async function server(task, opts) {
await task
.source('src/server/**/!(*.test).+(js|ts|tsx)')
.swc('server', { dev: opts.dev })
.target('dist/server')
await fs.copyFile(
join(__dirname, 'src/server/google-font-metrics.json'),
join(__dirname, 'dist/server/google-font-metrics.json')
)
}
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
export async function server_esm(task, opts) {
await task
.source('src/server/**/!(*.test).+(js|mts|ts|tsx)')
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
.swc('server', { dev: opts.dev, esm: true })
.target('dist/esm/server')
}
export async function nextbuild(task, opts) {
await task
Remove .test.js from dist (#55946) Noticed a couple of directories had unit tests in `dist` which are being run and reported during the Turbopack runs. These are generally quite small so I'm not expecting this to have much effect on the package size or CI runs, just making sure the data is correct. <!-- 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(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
2023-09-25 19:05:07 +02:00
.source('src/build/**/*.+(js|ts|tsx)', {
ignore: [
'**/fixture/**',
'**/tests/**',
'**/jest/**',
'**/*.test.d.ts',
'**/*.test.+(js|ts|tsx)',
],
})
.swc('server', { dev: opts.dev })
.target('dist/build')
}
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
export async function nextbuild_esm(task, opts) {
await task
Remove .test.js from dist (#55946) Noticed a couple of directories had unit tests in `dist` which are being run and reported during the Turbopack runs. These are generally quite small so I'm not expecting this to have much effect on the package size or CI runs, just making sure the data is correct. <!-- 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(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
2023-09-25 19:05:07 +02:00
.source('src/build/**/*.+(js|ts|tsx)', {
ignore: [
'**/fixture/**',
'**/tests/**',
'**/jest/**',
'**/*.test.d.ts',
'**/*.test.+(js|ts|tsx)',
],
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
})
.swc('server', { dev: opts.dev, esm: true })
.target('dist/esm/build')
}
export async function nextbuildjest(task, opts) {
await task
Remove .test.js from dist (#55946) Noticed a couple of directories had unit tests in `dist` which are being run and reported during the Turbopack runs. These are generally quite small so I'm not expecting this to have much effect on the package size or CI runs, just making sure the data is correct. <!-- 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(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
2023-09-25 19:05:07 +02:00
.source('src/build/jest/**/*.+(js|ts|tsx)', {
ignore: [
'**/fixture/**',
'**/tests/**',
'**/*.test.d.ts',
'**/*.test.+(js|ts|tsx)',
],
})
.swc('server', { dev: opts.dev, interopClientDefaultExport: true })
.target('dist/build/jest')
}
export async function client(task, opts) {
await task
.source('src/client/**/!(*.test).+(js|ts|tsx)')
.swc('client', { dev: opts.dev, interopClientDefaultExport: true })
.target('dist/client')
}
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
export async function client_esm(task, opts) {
await task
.source('src/client/**/!(*.test).+(js|ts|tsx)')
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
.swc('client', { dev: opts.dev, esm: true })
.target('dist/esm/client')
}
// export is a reserved keyword for functions
export async function nextbuildstatic(task, opts) {
await task
.source('src/export/**/!(*.test).+(js|ts|tsx)')
.swc('server', { dev: opts.dev })
.target('dist/export')
}
export async function pages_app(task, opts) {
await task
.source('src/pages/_app.tsx')
.swc('client', {
dev: opts.dev,
keepImportAttributes: true,
emitAssertForImportAttributes: true,
interopClientDefaultExport: true,
})
.target('dist/pages')
}
export async function pages_error(task, opts) {
await task
.source('src/pages/_error.tsx')
.swc('client', {
dev: opts.dev,
keepImportAttributes: true,
emitAssertForImportAttributes: true,
interopClientDefaultExport: true,
})
.target('dist/pages')
}
export async function pages_document(task, opts) {
await task
.source('src/pages/_document.tsx')
.swc('server', {
dev: opts.dev,
keepImportAttributes: true,
emitAssertForImportAttributes: true,
})
.target('dist/pages')
}
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
export async function pages_app_esm(task, opts) {
await task
.source('src/pages/_app.tsx')
.swc('client', {
dev: opts.dev,
keepImportAttributes: true,
emitAssertForImportAttributes: true,
esm: true,
})
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
.target('dist/esm/pages')
}
export async function pages_error_esm(task, opts) {
await task
.source('src/pages/_error.tsx')
.swc('client', {
dev: opts.dev,
keepImportAttributes: true,
emitAssertForImportAttributes: true,
esm: true,
})
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
.target('dist/esm/pages')
}
export async function pages_document_esm(task, opts) {
await task
.source('src/pages/_document.tsx')
.swc('server', {
dev: opts.dev,
keepImportAttributes: true,
emitAssertForImportAttributes: true,
esm: true,
})
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
.target('dist/esm/pages')
}
export async function pages(task, opts) {
await task.parallel(['pages_app', 'pages_error', 'pages_document'], opts)
}
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
export async function pages_esm(task, opts) {
await task.parallel(
['pages_app_esm', 'pages_error_esm', 'pages_document_esm'],
opts
)
}
export async function telemetry(task, opts) {
await task
.source('src/telemetry/**/*.+(js|ts|tsx)')
.swc('server', { dev: opts.dev })
.target('dist/telemetry')
}
export async function trace(task, opts) {
await task
.source('src/trace/**/*.+(js|ts|tsx)')
.swc('server', { dev: opts.dev })
.target('dist/trace')
}
export async function build(task, opts) {
refactor: rewrite config schema in zod (#56383) The PR supersedes the https://github.com/vercel/next.js/pull/53150, which is way too outdated, has way too many conflicts, and also heavily relies on GitHub Copilot (which makes the progress slow and tedious). The PR uses [`json-schema-to-zod`](https://github.com/StefanTerdell/json-schema-to-zod) (instead of the GitHub Copilot) to generate the zod schema, and manually replaces all generated `z.customRefine` with my hand-written zod schema. TODO: - [x] Convert schema - [x] Reduce `z.any()` usage - [x] Create human-readable errors from the `ZodError` - [x] Update test cases to reflect the latest error message ----- The benefit of using zod over ajv: - Easier maintenance: zod schema is straightforward to compose. - Better typescript support: config schema now strictly reflects the `NextConfig` type. - Smaller installation size: by replacing `ajv` and `@segment/ajv-human-errors` w/ `zod`, I am able to reduce installation size by 114 KiB. - Better Extension: the zod error message is easy to customize. ----- In the previous PR https://github.com/vercel/next.js/pull/56083, @feedthejim replaces `zod` w/ `superstruct`. `superstruct` is lightweight and fast, which makes it perfect for creating simple schemas for RSC payload. But, this also means `superstruct` has its limitations compared to `zod`: - `superstruct`'s syntax is different, and some utilities's usage is counter-intuitive: - `z.array(z.string()).gt(1)` vs `s.size(s.array(s.string()), 1)` - `z.numer().gt(1)` vs `s.size(s.number(), 1)`, `s.min(s.number(), 1)` - `z.boolean().optional().nullable()` vs `s.nullable(s.optional(z.boolean()))` - `superstruct` has weaker TypeScript support and worse DX compared to `zod` when composing huge schema: - `zod.ZodType + z.object()` can provide a more detailed type mismatch message on which specific property is the culprit, while `Describe + s.object()` provides almost no information at all. - `zod`'s schema is more powerful - `z.function()` supports `z.args()` and `z.returns()`, while `superstruct` only has `s.func()` - zod also has Promise type `z.promise()` and intersection type `z.and()` - `superstruct`'s error is harder to parse compared to `zod`'s `ZodError` So in the PR, I re-introduced `zod` for `next.config.js` validation.
2023-10-05 17:46:53 +02:00
await task.serial(['precompile', 'compile', 'generate_types'], opts)
}
export async function generate_types(task, opts) {
await execa.command('pnpm run types', {
stdio: 'inherit',
})
}
2020-05-18 21:24:37 +02:00
export default async function (task) {
const opts = { dev: true }
2018-11-30 13:10:30 +01:00
await task.clear('dist')
await task.start('build', opts)
2023-01-03 15:52:18 +01:00
await task.watch('src/bin', 'bin', opts)
await task.watch('src/pages', 'pages', opts)
await task.watch('src/server', ['server', 'server_esm', 'server_wasm'], opts)
await task.watch(
2023-01-03 15:52:18 +01:00
'src/build',
['nextbuild', 'nextbuild_esm', 'nextbuildjest'],
opts
)
2023-01-03 15:52:18 +01:00
await task.watch('src/export', 'nextbuildstatic', opts)
await task.watch('src/client', 'client', opts)
await task.watch('src/client', 'client_esm', opts)
await task.watch('src/lib', 'lib', opts)
await task.watch('src/lib', 'lib_esm', opts)
await task.watch('src/cli', 'cli', opts)
await task.watch('src/telemetry', 'telemetry', opts)
await task.watch('src/trace', 'trace', opts)
await task.watch(
2023-01-03 15:52:18 +01:00
'src/shared',
['shared_re_exported', 'shared_re_exported_esm', 'shared', 'shared_esm'],
opts
)
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
await task.watch(
'../react-dev-overlay/dist',
'ncc_next__react_dev_overlay',
opts
)
}
export async function shared(task, opts) {
await task
Remove .test.js from dist (#55946) Noticed a couple of directories had unit tests in `dist` which are being run and reported during the Turbopack runs. These are generally quite small so I'm not expecting this to have much effect on the package size or CI runs, just making sure the data is correct. <!-- 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(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
2023-09-25 19:05:07 +02:00
.source('src/shared/**/*.+(js|ts|tsx)', {
ignore: [
'src/shared/**/{amp,config,constants,dynamic,app-dynamic,head,runtime-config}.+(js|ts|tsx)',
'**/*.test.d.ts',
'**/*.test.+(js|ts|tsx)',
],
})
.swc('client', { dev: opts.dev })
.target('dist/shared')
}
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
export async function shared_esm(task, opts) {
await task
Remove .test.js from dist (#55946) Noticed a couple of directories had unit tests in `dist` which are being run and reported during the Turbopack runs. These are generally quite small so I'm not expecting this to have much effect on the package size or CI runs, just making sure the data is correct. <!-- 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(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
2023-09-25 19:05:07 +02:00
.source('src/shared/**/*.+(js|ts|tsx)', {
ignore: [
'src/shared/**/{amp,config,constants,dynamic,app-dynamic,head,runtime-config}.+(js|ts|tsx)',
'**/*.test.d.ts',
'**/*.test.+(js|ts|tsx)',
],
})
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
.swc('client', { dev: opts.dev, esm: true })
.target('dist/esm/shared')
}
export async function shared_re_exported(task, opts) {
await task
.source(
Remove .test.js from dist (#55946) Noticed a couple of directories had unit tests in `dist` which are being run and reported during the Turbopack runs. These are generally quite small so I'm not expecting this to have much effect on the package size or CI runs, just making sure the data is correct. <!-- 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(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
2023-09-25 19:05:07 +02:00
'src/shared/**/{amp,config,constants,dynamic,app-dynamic,head,runtime-config}.+(js|ts|tsx)',
{
ignore: ['**/*.test.d.ts', '**/*.test.+(js|ts|tsx)'],
}
)
.swc('client', { dev: opts.dev, interopClientDefaultExport: true })
.target('dist/shared')
}
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
export async function shared_re_exported_esm(task, opts) {
await task
.source(
Remove .test.js from dist (#55946) Noticed a couple of directories had unit tests in `dist` which are being run and reported during the Turbopack runs. These are generally quite small so I'm not expecting this to have much effect on the package size or CI runs, just making sure the data is correct. <!-- 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(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->
2023-09-25 19:05:07 +02:00
'src/shared/**/{amp,config,constants,app-dynamic,dynamic,head}.+(js|ts|tsx)',
{
ignore: ['**/*.test.d.ts', '**/*.test.+(js|ts|tsx)'],
}
)
edge-ssr: bundle next/dist as ESM for better tree-shaking (#40251) (#40980) Re-do of https://github.com/vercel/next.js/pull/40251 Edge SSR'd routes cold boot performances are proportional to the executed code size. In order to improve it, we are trying to optimize for the bundle size of a packed Edge SSR route. This PR adds ESM compilation targets for all Next.js dist packages and use them to bundle Edge SSR'd route. This allows us to leverage the better tree shaking/DCE for ESM modules in webpack in order to decrease the overall bundle size. This PR also enables minifying Edge SSR routes. Since we don't control which minifier might be used later (if any), it's best if we provide an already optimised bundle. <img width="903" alt="image" src="https://user-images.githubusercontent.com/11064311/190005211-b7cb2c58-a56a-44b0-8ee4-fd3f603e41bd.png"> This is a 10ms cold boot win per my benchmarking script, which I'll put in a subsequent PR. Not done yet: - ~~swap exported requires in `next/link` (and others) etc to point them to the esm modules version~~ <!-- 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: --> - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` - [x] 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` - [ ] 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: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in> <!-- 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: --> ## Bug - [ ] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a 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 a 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/examples/adding-examples.md) Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Shu Ding <g@shud.in>
2022-09-28 12:29:22 +02:00
.swc('client', {
dev: opts.dev,
esm: true,
})
.target('dist/esm/shared')
}
export async function server_wasm(task, opts) {
await task.source('src/server/**/*.+(wasm)').target('dist/server')
}
export async function experimental_testmode(task, opts) {
await task
.source('src/experimental/testmode/**/!(*.test).+(js|ts|tsx)')
.swc('server', {})
.target('dist/experimental/testmode')
}
export async function release(task) {
await task.clear('dist').start('build')
}
server: bundle vendored react (#55362) ## What This PR changes Next.js to bundle its vendored React libraries so that the App Router pages can use those built-in versions. ## Why Next.js supports both Pages and App Router and we've gone through a lot of iteration to make sure that Next.js stays flexible wrt to the version of React used: in Pages, we want to use the React provided by the user and in the App Router, to be able to use it, we need to use the canary version of React, which we've built into Next.js for convenience. The problem stems from the fact that you can't run two different instances of React (by design). Previously we have a dual worker setup, where we would separate completely each Next.js versions (App and Pages) so that they would not overlap with each other, however this approach was not great performance and memory wise. We've recently tried using an ESM loader and a single process, but this change would still opt you into the React canary version if you had an app page, which breaks some assumptions. ## How A list of the changes in this PR: ### New versions of the Next.js runtime Since we now compile a runtime per type of page (app/route/api/pages), in order to bundle the two versions of React that we vendored, we introduced a new type of bundle suffixed by `-experimental`. This bundle will have the bleeding edge React needed for Server Actions and Next.js will opt you in into that runtime automatically. For internal contributors, it means that we now run a compiler for 10 subparts of Next.js: - next_bundle_server - next_bundle_pages_prod - next_bundle_pages_turbo - next_bundle_pages_dev - next_bundle_app_turbo_experimental - next_bundle_app_prod - next_bundle_app_prod_experimental - next_bundle_app_turbo - next_bundle_app_dev_experimental - next_bundle_app_dev ![image](https://github.com/vercel/next.js/assets/11064311/f340417d-845e-45b9-8e86-5b287a295c82) ### Simplified require-hook Since the versions of React are correctly re-routed at build time for app pages, we don't need the require hook anymore ### Turbopack changes The bundling logic in Turbopack has been addressed to properly follow the new logic ### Changes to the shared contexts system Some context files need to have a shared instance between the rendering runtime and the user code, like the one that powers the `next/image` component. In general, the aliasing setup takes care of that but we need the require hook for code that is not compiled to reroute to the correct runtime. This only happens for pages node_modules. A new Turbopack resolving plugin has been added to handle that logic in Turbopack. ### Misc changes - `runtime-config` (that powers `next/config`) has been converted to an `.external` file, as it should have been - there are some rules that have been added to the aliases to support the usage of `react-dom/server` in a server-components. We can do that now since the runtime takes care of separating the versions of React. Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2023-09-15 21:49:39 +02:00
export async function next_bundle_app_turbo(task, opts) {
await task.source('dist').webpack({
watch: opts.dev,
config: require('./webpack.config')({
turbo: true,
bundleType: 'app',
}),
name: 'next-bundle-app-turbo',
})
}
export async function next_bundle_app_prod(task, opts) {
await task.source('dist').webpack({
watch: opts.dev,
config: require('./webpack.config')({
dev: false,
server: bundle vendored react (#55362) ## What This PR changes Next.js to bundle its vendored React libraries so that the App Router pages can use those built-in versions. ## Why Next.js supports both Pages and App Router and we've gone through a lot of iteration to make sure that Next.js stays flexible wrt to the version of React used: in Pages, we want to use the React provided by the user and in the App Router, to be able to use it, we need to use the canary version of React, which we've built into Next.js for convenience. The problem stems from the fact that you can't run two different instances of React (by design). Previously we have a dual worker setup, where we would separate completely each Next.js versions (App and Pages) so that they would not overlap with each other, however this approach was not great performance and memory wise. We've recently tried using an ESM loader and a single process, but this change would still opt you into the React canary version if you had an app page, which breaks some assumptions. ## How A list of the changes in this PR: ### New versions of the Next.js runtime Since we now compile a runtime per type of page (app/route/api/pages), in order to bundle the two versions of React that we vendored, we introduced a new type of bundle suffixed by `-experimental`. This bundle will have the bleeding edge React needed for Server Actions and Next.js will opt you in into that runtime automatically. For internal contributors, it means that we now run a compiler for 10 subparts of Next.js: - next_bundle_server - next_bundle_pages_prod - next_bundle_pages_turbo - next_bundle_pages_dev - next_bundle_app_turbo_experimental - next_bundle_app_prod - next_bundle_app_prod_experimental - next_bundle_app_turbo - next_bundle_app_dev_experimental - next_bundle_app_dev ![image](https://github.com/vercel/next.js/assets/11064311/f340417d-845e-45b9-8e86-5b287a295c82) ### Simplified require-hook Since the versions of React are correctly re-routed at build time for app pages, we don't need the require hook anymore ### Turbopack changes The bundling logic in Turbopack has been addressed to properly follow the new logic ### Changes to the shared contexts system Some context files need to have a shared instance between the rendering runtime and the user code, like the one that powers the `next/image` component. In general, the aliasing setup takes care of that but we need the require hook for code that is not compiled to reroute to the correct runtime. This only happens for pages node_modules. A new Turbopack resolving plugin has been added to handle that logic in Turbopack. ### Misc changes - `runtime-config` (that powers `next/config`) has been converted to an `.external` file, as it should have been - there are some rules that have been added to the aliases to support the usage of `react-dom/server` in a server-components. We can do that now since the runtime takes care of separating the versions of React. Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2023-09-15 21:49:39 +02:00
bundleType: 'app',
}),
server: bundle vendored react (#55362) ## What This PR changes Next.js to bundle its vendored React libraries so that the App Router pages can use those built-in versions. ## Why Next.js supports both Pages and App Router and we've gone through a lot of iteration to make sure that Next.js stays flexible wrt to the version of React used: in Pages, we want to use the React provided by the user and in the App Router, to be able to use it, we need to use the canary version of React, which we've built into Next.js for convenience. The problem stems from the fact that you can't run two different instances of React (by design). Previously we have a dual worker setup, where we would separate completely each Next.js versions (App and Pages) so that they would not overlap with each other, however this approach was not great performance and memory wise. We've recently tried using an ESM loader and a single process, but this change would still opt you into the React canary version if you had an app page, which breaks some assumptions. ## How A list of the changes in this PR: ### New versions of the Next.js runtime Since we now compile a runtime per type of page (app/route/api/pages), in order to bundle the two versions of React that we vendored, we introduced a new type of bundle suffixed by `-experimental`. This bundle will have the bleeding edge React needed for Server Actions and Next.js will opt you in into that runtime automatically. For internal contributors, it means that we now run a compiler for 10 subparts of Next.js: - next_bundle_server - next_bundle_pages_prod - next_bundle_pages_turbo - next_bundle_pages_dev - next_bundle_app_turbo_experimental - next_bundle_app_prod - next_bundle_app_prod_experimental - next_bundle_app_turbo - next_bundle_app_dev_experimental - next_bundle_app_dev ![image](https://github.com/vercel/next.js/assets/11064311/f340417d-845e-45b9-8e86-5b287a295c82) ### Simplified require-hook Since the versions of React are correctly re-routed at build time for app pages, we don't need the require hook anymore ### Turbopack changes The bundling logic in Turbopack has been addressed to properly follow the new logic ### Changes to the shared contexts system Some context files need to have a shared instance between the rendering runtime and the user code, like the one that powers the `next/image` component. In general, the aliasing setup takes care of that but we need the require hook for code that is not compiled to reroute to the correct runtime. This only happens for pages node_modules. A new Turbopack resolving plugin has been added to handle that logic in Turbopack. ### Misc changes - `runtime-config` (that powers `next/config`) has been converted to an `.external` file, as it should have been - there are some rules that have been added to the aliases to support the usage of `react-dom/server` in a server-components. We can do that now since the runtime takes care of separating the versions of React. Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2023-09-15 21:49:39 +02:00
name: 'next-bundle-app-prod',
})
}
server: bundle vendored react (#55362) ## What This PR changes Next.js to bundle its vendored React libraries so that the App Router pages can use those built-in versions. ## Why Next.js supports both Pages and App Router and we've gone through a lot of iteration to make sure that Next.js stays flexible wrt to the version of React used: in Pages, we want to use the React provided by the user and in the App Router, to be able to use it, we need to use the canary version of React, which we've built into Next.js for convenience. The problem stems from the fact that you can't run two different instances of React (by design). Previously we have a dual worker setup, where we would separate completely each Next.js versions (App and Pages) so that they would not overlap with each other, however this approach was not great performance and memory wise. We've recently tried using an ESM loader and a single process, but this change would still opt you into the React canary version if you had an app page, which breaks some assumptions. ## How A list of the changes in this PR: ### New versions of the Next.js runtime Since we now compile a runtime per type of page (app/route/api/pages), in order to bundle the two versions of React that we vendored, we introduced a new type of bundle suffixed by `-experimental`. This bundle will have the bleeding edge React needed for Server Actions and Next.js will opt you in into that runtime automatically. For internal contributors, it means that we now run a compiler for 10 subparts of Next.js: - next_bundle_server - next_bundle_pages_prod - next_bundle_pages_turbo - next_bundle_pages_dev - next_bundle_app_turbo_experimental - next_bundle_app_prod - next_bundle_app_prod_experimental - next_bundle_app_turbo - next_bundle_app_dev_experimental - next_bundle_app_dev ![image](https://github.com/vercel/next.js/assets/11064311/f340417d-845e-45b9-8e86-5b287a295c82) ### Simplified require-hook Since the versions of React are correctly re-routed at build time for app pages, we don't need the require hook anymore ### Turbopack changes The bundling logic in Turbopack has been addressed to properly follow the new logic ### Changes to the shared contexts system Some context files need to have a shared instance between the rendering runtime and the user code, like the one that powers the `next/image` component. In general, the aliasing setup takes care of that but we need the require hook for code that is not compiled to reroute to the correct runtime. This only happens for pages node_modules. A new Turbopack resolving plugin has been added to handle that logic in Turbopack. ### Misc changes - `runtime-config` (that powers `next/config`) has been converted to an `.external` file, as it should have been - there are some rules that have been added to the aliases to support the usage of `react-dom/server` in a server-components. We can do that now since the runtime takes care of separating the versions of React. Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2023-09-15 21:49:39 +02:00
export async function next_bundle_app_dev(task, opts) {
await task.source('dist').webpack({
watch: opts.dev,
config: require('./webpack.config')({
dev: true,
server: bundle vendored react (#55362) ## What This PR changes Next.js to bundle its vendored React libraries so that the App Router pages can use those built-in versions. ## Why Next.js supports both Pages and App Router and we've gone through a lot of iteration to make sure that Next.js stays flexible wrt to the version of React used: in Pages, we want to use the React provided by the user and in the App Router, to be able to use it, we need to use the canary version of React, which we've built into Next.js for convenience. The problem stems from the fact that you can't run two different instances of React (by design). Previously we have a dual worker setup, where we would separate completely each Next.js versions (App and Pages) so that they would not overlap with each other, however this approach was not great performance and memory wise. We've recently tried using an ESM loader and a single process, but this change would still opt you into the React canary version if you had an app page, which breaks some assumptions. ## How A list of the changes in this PR: ### New versions of the Next.js runtime Since we now compile a runtime per type of page (app/route/api/pages), in order to bundle the two versions of React that we vendored, we introduced a new type of bundle suffixed by `-experimental`. This bundle will have the bleeding edge React needed for Server Actions and Next.js will opt you in into that runtime automatically. For internal contributors, it means that we now run a compiler for 10 subparts of Next.js: - next_bundle_server - next_bundle_pages_prod - next_bundle_pages_turbo - next_bundle_pages_dev - next_bundle_app_turbo_experimental - next_bundle_app_prod - next_bundle_app_prod_experimental - next_bundle_app_turbo - next_bundle_app_dev_experimental - next_bundle_app_dev ![image](https://github.com/vercel/next.js/assets/11064311/f340417d-845e-45b9-8e86-5b287a295c82) ### Simplified require-hook Since the versions of React are correctly re-routed at build time for app pages, we don't need the require hook anymore ### Turbopack changes The bundling logic in Turbopack has been addressed to properly follow the new logic ### Changes to the shared contexts system Some context files need to have a shared instance between the rendering runtime and the user code, like the one that powers the `next/image` component. In general, the aliasing setup takes care of that but we need the require hook for code that is not compiled to reroute to the correct runtime. This only happens for pages node_modules. A new Turbopack resolving plugin has been added to handle that logic in Turbopack. ### Misc changes - `runtime-config` (that powers `next/config`) has been converted to an `.external` file, as it should have been - there are some rules that have been added to the aliases to support the usage of `react-dom/server` in a server-components. We can do that now since the runtime takes care of separating the versions of React. Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2023-09-15 21:49:39 +02:00
bundleType: 'app',
}),
server: bundle vendored react (#55362) ## What This PR changes Next.js to bundle its vendored React libraries so that the App Router pages can use those built-in versions. ## Why Next.js supports both Pages and App Router and we've gone through a lot of iteration to make sure that Next.js stays flexible wrt to the version of React used: in Pages, we want to use the React provided by the user and in the App Router, to be able to use it, we need to use the canary version of React, which we've built into Next.js for convenience. The problem stems from the fact that you can't run two different instances of React (by design). Previously we have a dual worker setup, where we would separate completely each Next.js versions (App and Pages) so that they would not overlap with each other, however this approach was not great performance and memory wise. We've recently tried using an ESM loader and a single process, but this change would still opt you into the React canary version if you had an app page, which breaks some assumptions. ## How A list of the changes in this PR: ### New versions of the Next.js runtime Since we now compile a runtime per type of page (app/route/api/pages), in order to bundle the two versions of React that we vendored, we introduced a new type of bundle suffixed by `-experimental`. This bundle will have the bleeding edge React needed for Server Actions and Next.js will opt you in into that runtime automatically. For internal contributors, it means that we now run a compiler for 10 subparts of Next.js: - next_bundle_server - next_bundle_pages_prod - next_bundle_pages_turbo - next_bundle_pages_dev - next_bundle_app_turbo_experimental - next_bundle_app_prod - next_bundle_app_prod_experimental - next_bundle_app_turbo - next_bundle_app_dev_experimental - next_bundle_app_dev ![image](https://github.com/vercel/next.js/assets/11064311/f340417d-845e-45b9-8e86-5b287a295c82) ### Simplified require-hook Since the versions of React are correctly re-routed at build time for app pages, we don't need the require hook anymore ### Turbopack changes The bundling logic in Turbopack has been addressed to properly follow the new logic ### Changes to the shared contexts system Some context files need to have a shared instance between the rendering runtime and the user code, like the one that powers the `next/image` component. In general, the aliasing setup takes care of that but we need the require hook for code that is not compiled to reroute to the correct runtime. This only happens for pages node_modules. A new Turbopack resolving plugin has been added to handle that logic in Turbopack. ### Misc changes - `runtime-config` (that powers `next/config`) has been converted to an `.external` file, as it should have been - there are some rules that have been added to the aliases to support the usage of `react-dom/server` in a server-components. We can do that now since the runtime takes care of separating the versions of React. Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2023-09-15 21:49:39 +02:00
name: 'next-bundle-app-dev',
})
}
server: bundle vendored react (#55362) ## What This PR changes Next.js to bundle its vendored React libraries so that the App Router pages can use those built-in versions. ## Why Next.js supports both Pages and App Router and we've gone through a lot of iteration to make sure that Next.js stays flexible wrt to the version of React used: in Pages, we want to use the React provided by the user and in the App Router, to be able to use it, we need to use the canary version of React, which we've built into Next.js for convenience. The problem stems from the fact that you can't run two different instances of React (by design). Previously we have a dual worker setup, where we would separate completely each Next.js versions (App and Pages) so that they would not overlap with each other, however this approach was not great performance and memory wise. We've recently tried using an ESM loader and a single process, but this change would still opt you into the React canary version if you had an app page, which breaks some assumptions. ## How A list of the changes in this PR: ### New versions of the Next.js runtime Since we now compile a runtime per type of page (app/route/api/pages), in order to bundle the two versions of React that we vendored, we introduced a new type of bundle suffixed by `-experimental`. This bundle will have the bleeding edge React needed for Server Actions and Next.js will opt you in into that runtime automatically. For internal contributors, it means that we now run a compiler for 10 subparts of Next.js: - next_bundle_server - next_bundle_pages_prod - next_bundle_pages_turbo - next_bundle_pages_dev - next_bundle_app_turbo_experimental - next_bundle_app_prod - next_bundle_app_prod_experimental - next_bundle_app_turbo - next_bundle_app_dev_experimental - next_bundle_app_dev ![image](https://github.com/vercel/next.js/assets/11064311/f340417d-845e-45b9-8e86-5b287a295c82) ### Simplified require-hook Since the versions of React are correctly re-routed at build time for app pages, we don't need the require hook anymore ### Turbopack changes The bundling logic in Turbopack has been addressed to properly follow the new logic ### Changes to the shared contexts system Some context files need to have a shared instance between the rendering runtime and the user code, like the one that powers the `next/image` component. In general, the aliasing setup takes care of that but we need the require hook for code that is not compiled to reroute to the correct runtime. This only happens for pages node_modules. A new Turbopack resolving plugin has been added to handle that logic in Turbopack. ### Misc changes - `runtime-config` (that powers `next/config`) has been converted to an `.external` file, as it should have been - there are some rules that have been added to the aliases to support the usage of `react-dom/server` in a server-components. We can do that now since the runtime takes care of separating the versions of React. Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2023-09-15 21:49:39 +02:00
export async function next_bundle_app_turbo_experimental(task, opts) {
await task.source('dist').webpack({
watch: opts.dev,
config: require('./webpack.config')({
turbo: true,
server: bundle vendored react (#55362) ## What This PR changes Next.js to bundle its vendored React libraries so that the App Router pages can use those built-in versions. ## Why Next.js supports both Pages and App Router and we've gone through a lot of iteration to make sure that Next.js stays flexible wrt to the version of React used: in Pages, we want to use the React provided by the user and in the App Router, to be able to use it, we need to use the canary version of React, which we've built into Next.js for convenience. The problem stems from the fact that you can't run two different instances of React (by design). Previously we have a dual worker setup, where we would separate completely each Next.js versions (App and Pages) so that they would not overlap with each other, however this approach was not great performance and memory wise. We've recently tried using an ESM loader and a single process, but this change would still opt you into the React canary version if you had an app page, which breaks some assumptions. ## How A list of the changes in this PR: ### New versions of the Next.js runtime Since we now compile a runtime per type of page (app/route/api/pages), in order to bundle the two versions of React that we vendored, we introduced a new type of bundle suffixed by `-experimental`. This bundle will have the bleeding edge React needed for Server Actions and Next.js will opt you in into that runtime automatically. For internal contributors, it means that we now run a compiler for 10 subparts of Next.js: - next_bundle_server - next_bundle_pages_prod - next_bundle_pages_turbo - next_bundle_pages_dev - next_bundle_app_turbo_experimental - next_bundle_app_prod - next_bundle_app_prod_experimental - next_bundle_app_turbo - next_bundle_app_dev_experimental - next_bundle_app_dev ![image](https://github.com/vercel/next.js/assets/11064311/f340417d-845e-45b9-8e86-5b287a295c82) ### Simplified require-hook Since the versions of React are correctly re-routed at build time for app pages, we don't need the require hook anymore ### Turbopack changes The bundling logic in Turbopack has been addressed to properly follow the new logic ### Changes to the shared contexts system Some context files need to have a shared instance between the rendering runtime and the user code, like the one that powers the `next/image` component. In general, the aliasing setup takes care of that but we need the require hook for code that is not compiled to reroute to the correct runtime. This only happens for pages node_modules. A new Turbopack resolving plugin has been added to handle that logic in Turbopack. ### Misc changes - `runtime-config` (that powers `next/config`) has been converted to an `.external` file, as it should have been - there are some rules that have been added to the aliases to support the usage of `react-dom/server` in a server-components. We can do that now since the runtime takes care of separating the versions of React. Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2023-09-15 21:49:39 +02:00
bundleType: 'app',
experimental: true,
}),
name: 'next-bundle-app-turbo-experimental',
})
}
export async function next_bundle_app_prod_experimental(task, opts) {
await task.source('dist').webpack({
watch: opts.dev,
config: require('./webpack.config')({
dev: false,
bundleType: 'app',
experimental: true,
}),
server: bundle vendored react (#55362) ## What This PR changes Next.js to bundle its vendored React libraries so that the App Router pages can use those built-in versions. ## Why Next.js supports both Pages and App Router and we've gone through a lot of iteration to make sure that Next.js stays flexible wrt to the version of React used: in Pages, we want to use the React provided by the user and in the App Router, to be able to use it, we need to use the canary version of React, which we've built into Next.js for convenience. The problem stems from the fact that you can't run two different instances of React (by design). Previously we have a dual worker setup, where we would separate completely each Next.js versions (App and Pages) so that they would not overlap with each other, however this approach was not great performance and memory wise. We've recently tried using an ESM loader and a single process, but this change would still opt you into the React canary version if you had an app page, which breaks some assumptions. ## How A list of the changes in this PR: ### New versions of the Next.js runtime Since we now compile a runtime per type of page (app/route/api/pages), in order to bundle the two versions of React that we vendored, we introduced a new type of bundle suffixed by `-experimental`. This bundle will have the bleeding edge React needed for Server Actions and Next.js will opt you in into that runtime automatically. For internal contributors, it means that we now run a compiler for 10 subparts of Next.js: - next_bundle_server - next_bundle_pages_prod - next_bundle_pages_turbo - next_bundle_pages_dev - next_bundle_app_turbo_experimental - next_bundle_app_prod - next_bundle_app_prod_experimental - next_bundle_app_turbo - next_bundle_app_dev_experimental - next_bundle_app_dev ![image](https://github.com/vercel/next.js/assets/11064311/f340417d-845e-45b9-8e86-5b287a295c82) ### Simplified require-hook Since the versions of React are correctly re-routed at build time for app pages, we don't need the require hook anymore ### Turbopack changes The bundling logic in Turbopack has been addressed to properly follow the new logic ### Changes to the shared contexts system Some context files need to have a shared instance between the rendering runtime and the user code, like the one that powers the `next/image` component. In general, the aliasing setup takes care of that but we need the require hook for code that is not compiled to reroute to the correct runtime. This only happens for pages node_modules. A new Turbopack resolving plugin has been added to handle that logic in Turbopack. ### Misc changes - `runtime-config` (that powers `next/config`) has been converted to an `.external` file, as it should have been - there are some rules that have been added to the aliases to support the usage of `react-dom/server` in a server-components. We can do that now since the runtime takes care of separating the versions of React. Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2023-09-15 21:49:39 +02:00
name: 'next-bundle-app-prod-experimental',
})
}
server: bundle vendored react (#55362) ## What This PR changes Next.js to bundle its vendored React libraries so that the App Router pages can use those built-in versions. ## Why Next.js supports both Pages and App Router and we've gone through a lot of iteration to make sure that Next.js stays flexible wrt to the version of React used: in Pages, we want to use the React provided by the user and in the App Router, to be able to use it, we need to use the canary version of React, which we've built into Next.js for convenience. The problem stems from the fact that you can't run two different instances of React (by design). Previously we have a dual worker setup, where we would separate completely each Next.js versions (App and Pages) so that they would not overlap with each other, however this approach was not great performance and memory wise. We've recently tried using an ESM loader and a single process, but this change would still opt you into the React canary version if you had an app page, which breaks some assumptions. ## How A list of the changes in this PR: ### New versions of the Next.js runtime Since we now compile a runtime per type of page (app/route/api/pages), in order to bundle the two versions of React that we vendored, we introduced a new type of bundle suffixed by `-experimental`. This bundle will have the bleeding edge React needed for Server Actions and Next.js will opt you in into that runtime automatically. For internal contributors, it means that we now run a compiler for 10 subparts of Next.js: - next_bundle_server - next_bundle_pages_prod - next_bundle_pages_turbo - next_bundle_pages_dev - next_bundle_app_turbo_experimental - next_bundle_app_prod - next_bundle_app_prod_experimental - next_bundle_app_turbo - next_bundle_app_dev_experimental - next_bundle_app_dev ![image](https://github.com/vercel/next.js/assets/11064311/f340417d-845e-45b9-8e86-5b287a295c82) ### Simplified require-hook Since the versions of React are correctly re-routed at build time for app pages, we don't need the require hook anymore ### Turbopack changes The bundling logic in Turbopack has been addressed to properly follow the new logic ### Changes to the shared contexts system Some context files need to have a shared instance between the rendering runtime and the user code, like the one that powers the `next/image` component. In general, the aliasing setup takes care of that but we need the require hook for code that is not compiled to reroute to the correct runtime. This only happens for pages node_modules. A new Turbopack resolving plugin has been added to handle that logic in Turbopack. ### Misc changes - `runtime-config` (that powers `next/config`) has been converted to an `.external` file, as it should have been - there are some rules that have been added to the aliases to support the usage of `react-dom/server` in a server-components. We can do that now since the runtime takes care of separating the versions of React. Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2023-09-15 21:49:39 +02:00
export async function next_bundle_app_dev_experimental(task, opts) {
await task.source('dist').webpack({
watch: opts.dev,
config: require('./webpack.config')({
dev: true,
bundleType: 'app',
experimental: true,
}),
name: 'next-bundle-app-dev-experimental',
})
}
export async function next_bundle_pages_prod(task, opts) {
await task.source('dist').webpack({
watch: opts.dev,
config: require('./webpack.config')({
dev: false,
bundleType: 'pages',
}),
name: 'next-bundle-pages-prod',
})
}
export async function next_bundle_pages_dev(task, opts) {
await task.source('dist').webpack({
watch: opts.dev,
config: require('./webpack.config')({
dev: true,
bundleType: 'pages',
}),
name: 'next-bundle-pages-dev',
})
}
export async function next_bundle_pages_turbo(task, opts) {
await task.source('dist').webpack({
watch: opts.dev,
config: require('./webpack.config')({
turbo: true,
bundleType: 'pages',
}),
name: 'next-bundle-pages-turbo',
})
}
export async function next_bundle_server(task, opts) {
await task.source('dist').webpack({
watch: opts.dev,
config: require('./webpack.config')({
dev: false,
bundleType: 'server',
}),
name: 'next-bundle-server',
})
}
export async function next_bundle(task, opts) {
await task.parallel(
server: bundle vendored react (#55362) ## What This PR changes Next.js to bundle its vendored React libraries so that the App Router pages can use those built-in versions. ## Why Next.js supports both Pages and App Router and we've gone through a lot of iteration to make sure that Next.js stays flexible wrt to the version of React used: in Pages, we want to use the React provided by the user and in the App Router, to be able to use it, we need to use the canary version of React, which we've built into Next.js for convenience. The problem stems from the fact that you can't run two different instances of React (by design). Previously we have a dual worker setup, where we would separate completely each Next.js versions (App and Pages) so that they would not overlap with each other, however this approach was not great performance and memory wise. We've recently tried using an ESM loader and a single process, but this change would still opt you into the React canary version if you had an app page, which breaks some assumptions. ## How A list of the changes in this PR: ### New versions of the Next.js runtime Since we now compile a runtime per type of page (app/route/api/pages), in order to bundle the two versions of React that we vendored, we introduced a new type of bundle suffixed by `-experimental`. This bundle will have the bleeding edge React needed for Server Actions and Next.js will opt you in into that runtime automatically. For internal contributors, it means that we now run a compiler for 10 subparts of Next.js: - next_bundle_server - next_bundle_pages_prod - next_bundle_pages_turbo - next_bundle_pages_dev - next_bundle_app_turbo_experimental - next_bundle_app_prod - next_bundle_app_prod_experimental - next_bundle_app_turbo - next_bundle_app_dev_experimental - next_bundle_app_dev ![image](https://github.com/vercel/next.js/assets/11064311/f340417d-845e-45b9-8e86-5b287a295c82) ### Simplified require-hook Since the versions of React are correctly re-routed at build time for app pages, we don't need the require hook anymore ### Turbopack changes The bundling logic in Turbopack has been addressed to properly follow the new logic ### Changes to the shared contexts system Some context files need to have a shared instance between the rendering runtime and the user code, like the one that powers the `next/image` component. In general, the aliasing setup takes care of that but we need the require hook for code that is not compiled to reroute to the correct runtime. This only happens for pages node_modules. A new Turbopack resolving plugin has been added to handle that logic in Turbopack. ### Misc changes - `runtime-config` (that powers `next/config`) has been converted to an `.external` file, as it should have been - there are some rules that have been added to the aliases to support the usage of `react-dom/server` in a server-components. We can do that now since the runtime takes care of separating the versions of React. Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
2023-09-15 21:49:39 +02:00
[
// builds the app (route/page) bundles
'next_bundle_app_turbo',
'next_bundle_app_prod',
'next_bundle_app_dev',
// builds the app (route/page) bundles with react experimental
'next_bundle_app_turbo_experimental',
'next_bundle_app_prod_experimental',
'next_bundle_app_dev_experimental',
// builds the pages (page/api) bundles
'next_bundle_pages_prod',
'next_bundle_pages_dev',
'next_bundle_pages_turbo',
// builds the minimal server
'next_bundle_server',
],
opts
)
}
function writeJson(file, obj, { spaces = 0 } = {}) {
return fs.writeFile(
file,
JSON.stringify(obj, null, spaces) + (spaces === 0 ? '\n' : '')
)
}
function rmrf(path, options) {
return fs.rm(path, { recursive: true, force: true, ...options })
}
function readJson(path) {
return fs.readFile(path, 'utf8').then((content) => JSON.parse(content))
}