8000 fix: accept every next config key in withreylo's type by colinhacks · Pull Request #73 · colinhacks/reylo · GitHub
[go: up one dir, main page]

Skip to content

fix: accept every next config key in withreylo's type - #73

Merged
colinhacks merged 3 commits into
mainfrom
fix-next-config-type
Oct 23, 2026
Merged

colinhacks merged 3 commits into
mainfrom
fix-next-config-type

Conversation

@colinhacks
@colinhacks colinhacks commented Oct 23, 2026 •
Copy link
Copy Markdown
Owner

withReylo's parameter type names only the Next config fields the wrapper reads, and every level of it has only optional properties, which makes it a weak type: a literal that shares none of its properties fails the generic constraint, and TypeScript reports the keys as excess properties. So ordinary configs failed next.config.ts's type check:

withReylo({ reactStrictMode: true });     // TS2353: 'reactStrictMode' does not exist in type 'NextConfig'
withReylo({ turbopack: { root: "/x" } }); // TS2353: 'root' does not exist in type '{ rules?: ... }'

Each level is now intersected with object, so it is no longer weak. An index signature would not do: Next's own NextConfig and its parts are interfaces, which have none, so withReylo(nextConfig), the form the docs show, would stop type-checking unless the signature's value were any.

Verified with TypeScript 7.1 against Next's NextConfig from both lab/nextjs and examples/nextjs, with exactOptionalPropertyTypes on and off:

  • the two calls above, and literals that also set typescript, compiler.removeConsole and turbopack.rules, type-check;
  • withReylo(nextConfig) with a NextConfig value type-checks, and its result is assignable to NextConfig;
  • known fields are still checked: ignoreBuildErrors: "yes", rules: 5, runAfterProductionCompile: 5 and typescript: true are errors.

A new test in tests/next.test.ts passes such a literal; against the old type it fails nub run typecheck with TS2353.

Copilot AI balanced review requested due to automatic review settings October 23, 2026 17:17
@vercel
vercel Bot commented Oct 23, 2026 •
Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Actions Updated
reylo Ignored Ignored Preview Oct 23, 2026 5:32pm UTC

Request Review

Copilot AI left a comment
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

@colinhacks colinhacks changed the title fix(mapper): accept every next config key in withreylo's type fix: accept every next config key in withreylo's type Oct 23, 2026
An object literal passed to withReylo was checked for excess properties against the narrow config type it reads, so keys such as reactStrictMode or turbopack.root failed next.config.ts's type check.
@colinhacks
colinhacks force-pushed the fix-next-config-type branch from 0115a2a to cb455a4 Compare October 23, 2026 17:17
@pullfrog pullfrog Bot left a comment
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ No critical issues — two small suggestions inline.

Reviewed changes

I reviewed the widening of withReylo's parameter type and its new regression test. I checked the type behaviour against the repo's TypeScript 7.1, and tests/next.test.ts passes (6/6).

  • Index signatures in NextConfig: the top level, typescript, turbopack and compiler now each take [key: string]: any. Literals like { reactStrictMode: true } and { turbopack: { root } } now type-check. Known fields are still checked: ignoreBuildErrors: "yes" is still an error. An interface-typed NextConfig value is still accepted, because a string index of any accepts interfaces.
  • Regression test: the new test passes keys that withReylo's type does not name, at every level the type names. Each nested object holds only such keys, so the test fails against the old type.

Pullfrog  | Fix all ➔ | Fix 👍s ➔ | View workflow run | Using claude-opus-5-5 | 𝕏

Comment thread src/next.ts Resolved
Comment thread tests/next.test.ts Resolved
An index signature broke a config typed as Next's own NextConfig, whose interfaces have none.
@pullfrog pullfrog Bot left a comment
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ No new issues. The only open item is the earlier assert.deepEqual nit in tests/next.test.ts.

Reviewed changes

Since the last review, the index signatures in withReylo's parameter type were replaced with intersections with object. I checked the new type with the repo's TypeScript 7.1, with exactOptionalPropertyTypes on, and tests/next.test.ts still passes (6/6).

  • Replaced index signatures with object &: the top level, typescript, turbopack and compiler are now object & { … }. These types are no longer weak, so { reactStrictMode: true }, { turbopack: { root } } and { compiler: { removeConsole } } type-check. withReylo() also type-checks. An interface-typed NextConfig value is accepted, and the result can be assigned back to it.
  • Known fields are checked more strictly: ignoreBuildErrors: "yes", rules: 5, typescript: true, runAfterProductionCompile: 5, webpack: 5, withReylo(5) and withReylo("x") are all errors. The old any-valued index signatures let a non-object value through at any level. Now every level must be an object.
  • Rewrote the type's comment: it now explains the weak-type mechanism correctly, which settles the earlier thread on it.

Pullfrog  | Fix it ➔ | View workflow run | Using claude-opus-5-5 | 𝕏

@colinhacks
colinhacks merged commit 82ee4c9 into main Oct 23, 2026
6 checks passed
@colinhacks
colinhacks deleted the fix-next-config-type branch October 23, 2026 17:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

0