Make a default overridable adapter in core#35
Conversation
…y into core adapter feat: enhance build process with additional server bundle customization options chore: update package.json scripts for improved build and testing workflow test: add unit tests for adapter build process and server bundle generation fix: ensure proper handling of external dependencies and edge configuration in server bundle
…ests for resolve plugin
…specific overrides
commit: |
…udflare specific overrides" This reverts commit 37c4d90.
…ad of throwing - Extract ValidateConfigResult type with success/message/shouldThrow/level - Convert validateFunctionOptions and validateSplittedFunctionOptions to return result objects - Remove logger dependency from validateConfig.ts - Preserve compatibilityMatrix, TODO comment, @ts-expect-error pragmas - Add 5 characterization tests in validateConfig.spec.ts - No caller impact: compileConfig.ts is the sole importer (updated in T3)
- Export OpenNextOutput interface (was internal) - Extract buildOpenNextOutput(buildOpts) for construction-only (no fs write) - Keep legacy generateOutput as thin wrapper (construction + file write) - Preserve all construction logic verbatim, including @ts-expect-error - Add 3 characterization tests in generateOutput.spec.ts - Backward compatible: byte-equivalent output to today
- Replace bare validateConfig(config) call with result-handling block - Throw on shouldThrow:true (bad routes — preserves existing behavior) - Log at appropriate level on shouldThrow:false (level field from T1) - All 3 export signatures and edge-runtime detection block unchanged - Direct callers (aws/build.ts, cloudflare/utils.ts) unaffected
…OpenNextAdapterOptions - Make OpenNextAdapterOptions<T = OpenNextOutput> and buildAdapter<T> generic - Add validateConfig override hook (runs after callback in modifyConfig) - Add generateOutput override hook (returns T, gated by skipGenerateOutput) - buildAdapter serializes override return via fs.writeFileSync (override never touches fs) - Default path uses buildOpenNextOutput (extracted in T2) - Add 5 new tests covering override behaviors + default path + skipGenerateOutput - All 16 existing adapter tests preserved; AWS/Cloudflare adapters compile with default T
When an adapter config specifies full package-specifier paths (e.g., @opennextjs/aws/overrides/wrappers/aws-lambda.js), esbuild cannot resolve them during bundling. Use createRequire(args.path).resolve() in the openNextResolvePlugin to convert package specifiers to filesystem-relative paths at build time, falling back to the original value if resolution fails. This fixes the openbuild:local build error: ERROR: Could not resolve "@opennextjs/aws/overrides/wrappers/aws-lambda.js" ERROR: Could not resolve "@opennextjs/aws/overrides/tagCache/dynamodb.js" Added test I verifying resolution of a mock package in node_modules.
| skipWarmer: true, | ||
| skipGenerateOutput: true, | ||
| middlewareOptions: { forceOnlyBuildOnce: true }, | ||
| beforeMiddleware: async (buildOpts, _config) => { |
There was a problem hiding this comment.
i think this might make more sense as beforeServerBundle given we have afterServerBundle now, and just consider middleware to be part of the server bundle step.
could potentially even be moved inside serverBundle as pre and post hooks.
| fs.copyFileSync(cache.cache, path.join(tempCachePath, "cache.cjs")); | ||
| fs.copyFileSync(cache.composableCache, path.join(tempCachePath, "composable-cache.cjs")); |
There was a problem hiding this comment.
couldnt these also be mjs files?
There was a problem hiding this comment.
shouldnt the ext be based on the ext of the original filename?
There was a problem hiding this comment.
I haven't tested it in a while, but the original reason was that Next didn't work with mjs at the time.
| }, | ||
|
|
||
| async onBuildComplete(ctx) { | ||
| console.log("OpenNext build will start now"); |
There was a problem hiding this comment.
is there a reason we're using console.log in here instead of our own logger fns?
There was a problem hiding this comment.
Nope, I just forgot about it 😄
| const { useTagCache } = createCacheAssets(buildOpts); | ||
| console.log("Cache assets created"); | ||
| if (useTagCache) { |
There was a problem hiding this comment.
this is just my react-pilled mind, but i always find it slightly odd seeing useThing naming to start variables instead of shouldUseThing 😅
| { | ||
| entryPoints: [path.join(options.openNextDistDir, "adapters", "server-adapter.js")], | ||
| external: ["next", "./middleware.mjs", "./next-server.runtime.prod.js"], | ||
| external: codeCustomization?.externals ?? ["next", "./middleware.mjs", "./next-server.runtime.prod.js"], |
There was a problem hiding this comment.
do we not want to treat custom externals as additive to the default ones? if not, what would you think of always having an adapter explicitely provide them?
i guess in cloudflare that means we only externalise middleware now instead of all 3. i think it might be clearer what's going on to have external be explicitely passed by each? WDYT?
There was a problem hiding this comment.
Yeah, I think that now that the build stuff is common and configurable, it make sense to provide them by each adapter, as this is likely something that people will want to customize
| * @returns | ||
| */ | ||
| export function openNextResolvePlugin({ overrides, fnName }: IPluginSettings): Plugin { | ||
| export function openNextResolvePlugin({ |
There was a problem hiding this comment.
can we look at if we're able to do something with the esbuild onResolve hook instead of the ast etc. stuff we're adding here?
There was a problem hiding this comment.
I guess I could give it a try yeah
Make a default overridable adapter in core.
Remove unused files and dependencies related to AWS, improve build processes, and update TypeScript and Node versions.
Enhance the AWS adapter with default overrides and integrate Cloudflare-specific configurations.
Clean up the codebase by removing outdated examples and unnecessary utilities. Fix various build and CI issues.