chore(deps): Bump actions/checkout from 5 to 6 (#1300)

feat: remove npm devDependency (#1332)

I believe this was causing npm publish to fail since its an outdated npm
version


https://github.com/vercel/ncc/actions/runs/27214803275/job/80353387410#step:13:440

feat: add publishConfig to package.json (#1331)

This appears to be necessary for trusted publishing

feat(ci): upgrade python and remove LLVM LTO flags from MSVC build to…

… fix Node 26 Windows CI (#1330)

## Root Cause

Node.js 26 on Windows is compiled using Clang with thin LTO enabled
(`enable_thin_lto=true`, `lto_jobs=2`). When `node-gyp rebuild` runs
without `--nodedir`, it generates `build/config.gypi` from the running
Node.js binary's `process.config`. This causes Node.js's `common.gypi`
to inject LLVM/Clang-specific flags into the MSVC build:

- `-flto=thin` → compiler/linker warning (ignored by MSVC)
- `/opt:lldltojobs=2` → **fatal linker error `LNK1117`** (MSVC does not
understand LLVM LTO job flags)

## Fix

Modified `test/binary/binding.gyp` to strip the incompatible LLVM LTO
flags when building on Windows with MSVC:

- Added a `"lto_jobs%": ""` default variable as a safe fallback for Node
versions that do not define this variable
- Added a Windows-specific `conditions` block using GYP's
`AdditionalOptions!` list-removal operator to remove `-flto=thin`,
`-flto=full`, and `/opt:lldltojobs=<(lto_jobs)` from both
`VCCLCompilerTool` and `VCLinkerTool` options

The fix is a no-op on Node 22/24 (LTO not enabled, no flags to remove)
and does not affect Linux or macOS builds.

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>

feat: delete .github/CODEOWNERS (#1324)

This is how our other repos are managed - they just require one approval
by a Vercelian.

For example, see https://github.com/vercel/ms

fix(security): Predictable global cache directory in /tmp enables sym…

…link/hijack risks (#1314)

## Problem

The cache directory is a fixed, shared path (`/tmp/ncc-cache`). On
multi-user systems this can be pre-created or manipulated by another
user (symlink/hardlink attacks), potentially causing cache poisoning,
unintended file writes, or data leakage between builds/users depending
on how cache files are later written.

**Severity**: `medium`
**File**: `src/utils/ncc-cache-dir.js`

## Solution

Use a per-user/per-project cache directory with secure creation
semantics (e.g., `fs.mkdtemp` under user-owned base dir), enforce
permissions (`0700`), and verify path is not a symlink before writing.

## Changes

- `src/utils/ncc-cache-dir.js` (modified)

## Testing

- [ ] Existing tests pass
- [ ] Manual review completed
- [ ] No new warnings/errors introduced

---------

Signed-off-by: tuanaiseo <221258316+tuanaiseo@users.noreply.github.com>
Co-authored-by: Steven <steven@ceriously.com>

fix: Reorder extension resolution to prioritise TypeScript over JSON (#…

…1315)

When a directory contains both `test.json` and `test.ts`, an
extensionless import like:

```ts
import { myFunction } from './test';
```

resolves to `test.json` instead of `test.ts`, causing all exported
methods from the TypeScript file to be unresolvable during the build.

Webpack resolves extensions in the order they appear in the
`resolve.extensions` array.

Since `.json` appears before `.ts` and `.tsx`, webpack picks the JSON
file first when both exist.

### Reproduce

(The test project need a `tsconfig.json` with
`compilerOptions.resolveJsonModule: true`)

1. Create a directory with two files sharing the same base name: 

   **`src/test.json`**
   ```json
   { "key": "value" }
   ```

   **`src/test.ts`**
   ```ts
   export function greet(): string {
     return "hello";
   }
   ```

2. Import without an extension from another TypeScript file:

   **`src/index.ts`**
   ```ts
   import { greet } from './test';
   console.log(greet());
   ```

3. Run `ncc build src/index.ts` the build fails because `./test`
resolves to `test.json`, which has no `greet` export.

feat: support TypeScript 6 transpile builds (#1316)

## Summary

Updates `ts-loader` to `9.5.7` so ncc's bundled TypeScript loader
preserves configured `rootDir` during `transpileModule` builds.

This fixes TypeScript 6 `TS5011` failures like:

```text
TS5011: The common source directory of 'tsconfig.json' is './actions/javascript/...'. The 'rootDir' setting must be explicitly set to this or another path to adjust your output's file layout.
```

`ts-loader` fixed this upstream in
TypeStrong/ts-loader#1679.

## Verification

- Ran `yarn build`

fix(cjs-build): enable evaluating import.meta in cjs build (#1236)

## Purpose

A while ago, a [PR](#897) was merged
to disable `import.meta` evaluation altogether to support new versions
of Webpack. This sometimes causes issues in CJS projects.

In the comments, there were some
[discussions](#897 (comment))
about whether we should have a conditional and keep the previous
behavior for CJS builds. This PR addresses exactly this by translating
`import.meta.url` to a CJS compatible statement which results to the
same output.

I have created a [comparative
build](https://github.com/meienberger/ncc/pull/1/files) between two
projects using the same code and a dependency (@sentry/node) that uses
`import.meta.url`. You can see the difference in the output `index.js`

Before the change:

```javascript
const importMetaUrl = typeof import.meta.url !== 'undefined' ? import.meta.url : undefined;
```

After:

```javascript
const importMetaUrl = typeof require("url").pathToFileURL(__filename).href !== 'undefined' ? require("url").pathToFileURL(__filename).href : undefined;
```

Closes #1019

fix: add missing `--asset-builds` to cli help message (#1228)

The `-a, --asset-builds` do exists and is useful in some
circumstances(#1049), but it seems
that the cli help message does not contain its usage description ( while
`README.md` has the description).

This PR add the description of `--asset-builds` to the cli help message.

---------

Co-authored-by: Steven <steven@ceriously.com>