Repository navigation
fix: accept every next config key in withreylo's type - #73
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
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.
0115a2a to
cb455a4
Compare
There was a problem hiding this comment.
ℹ️ 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,turbopackandcompilernow 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-typedNextConfigvalue is still accepted, because a string index ofanyaccepts 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.
claude-opus-5-5 | 𝕏
An index signature broke a config typed as Next's own NextConfig, whose interfaces have none.
There was a problem hiding this comment.
ℹ️ No new issues. The only open item is the earlier
assert.deepEqualnit intests/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,turbopackandcompilerare nowobject & { … }. These types are no longer weak, so{ reactStrictMode: true },{ turbopack: { root } }and{ compiler: { removeConsole } }type-check.withReylo()also type-checks. An interface-typedNextConfigvalue 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)andwithReylo("x")are all errors. The oldany-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.
claude-opus-5-5 | 𝕏

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 failednext.config.ts's type check:Each level is now intersected with
object, so it is no longer weak. An index signature would not do: Next's ownNextConfigand its parts are interfaces, which have none, sowithReylo(nextConfig), the form the docs show, would stop type-checking unless the signature's value wereany.Verified with TypeScript 7.1 against Next's
NextConfigfrom bothlab/nextjsandexamples/nextjs, withexactOptionalPropertyTypeson and off:typescript,compiler.removeConsoleandturbopack.rules, type-check;withReylo(nextConfig)with aNextConfigvalue type-checks, and its result is assignable toNextConfig;ignoreBuildErrors: "yes",rules: 5,runAfterProductionCompile: 5andtypescript: trueare errors.A new test in
tests/next.test.tspasses such a literal; against the old type it failsnub run typecheckwith TS2353.