### What?
Adds a `--deployable-tar` option to `pack-next` that writes generated
tarballs into the target project and patches package references to use
relative `file:` paths.
### Why?
Projects that need to deploy with locally packed Next.js packages should
be able to include those tarballs inside the project directory instead
of referencing tarballs from the Next.js checkout.
### How?
Resolves the target project package.json location, writes tarballs to a
sibling `tarballs/` directory, and maps package override paths to
project-relative references when patching package.json. Existing `--tar`
behavior continues to write to the repository tarballs directory.
### Verification
- `git diff --check`
- `git diff --cached --check`
- `pnpm prettier --with-node-modules --ignore-path .prettierignore
--write scripts/pack-next.ts scripts/pack-utils/patch-package-json.ts
contributing/core/testing.md contributing/core/developing.md`
- `npx eslint --config eslint.config.mjs --fix scripts/pack-next.ts
scripts/pack-utils/patch-package-json.ts contributing/core/testing.md
contributing/core/developing.md` (Markdown files were ignored because no
matching ESLint config was supplied)
- `pnpm pack-next --project ../sandbox/nextjs-duplicated-html-repro/
--deployable-tar`
<!-- NEXT_JS_LLM_PR -->
`type: 'string'` conflicts with `choices: T[]`. It's basically `string |
T` which just collapses to `string` if `T` is a union of string
literals.
Before:
```console
$ p pack-next --help
...
--compress ... [string] [choices: "none", "strip"]
```
After:
```console
$ p pack-next --help
...
--compress ... [choices: "none", "strip"]
The file already had the `@ts-check` directive, so the IDE did show errors in that file. But since it was not included in the root `tsconfig.json`, those errors were not reported during CI runs.
One issue found this way was that the `related` flag was defined but never used. The referenced script was removed in #67644.
The `patch-next.cjs` script is failing because two of its dependencies,
`pack-util` and `build-native`, are missing their CommonJS versions,
which are required for compatibility with the current Node.js
environment. To fix this, i added the transpiled `pack-util.js` and
`build-native.js` files.
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: Benjamin Woodruff <benjamin.woodruff@vercel.com>
Yargs automatically creates `--no-` variations of options. Using
`--no-js-build` as an option directly confuses it.
`--no-js-build` remains a valid cli argument.
Test Plan: Verify `pnpm pack-next` builds JS by default and `pnpm
pack-next --no-js-build` doesn’t.
Help now looks like this:
```
pack-next.ts
Options:
--help Show help [boolean]
--version Show version number [boolean]
--js-build Build JavaScript code (default). Use `--no-js-build` to skip
building JavaScript [boolean] [default: true]
-p, --project [string]
--tar Create tarballs instead of direct reflinks [boolean]
--compress How compress the binary, useful on platforms where tarballs
can exceed 2 GiB, which causes ERR_FS_FILE_TOO_LARGE with
pnpm. Defaults to "strip" on Linux, otherwise defaults to
"none". Requires `--tar` to be set.
[string] [choices: "none", "strip"]
```
Written with @bgw.
- Transitions to using `tsx` for script execution
- Replaces `patch-package` with TypeScript implementation
- Implements argument parsing and help message with `yargs`
- Uses `execa` for some command execution
Test Plan: Run `pnpm pack-next`, `pnpm swc-build-wasm`, `pnpm unpack-next`, and `pnpm sweep` without errors.
Tim Neutkens