Skip to content

Make a default overridable adapter in core#35

Open
conico974 wants to merge 13 commits into
conico/core-rewritefrom
conico/share-build
Open

Make a default overridable adapter in core#35
conico974 wants to merge 13 commits into
conico/core-rewritefrom
conico/share-build

Conversation

@conico974

@conico974 conico974 commented Jun 27, 2026

Copy link
Copy Markdown
Contributor

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.


Open in Devin Review

…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
@pkg-pr-new

pkg-pr-new Bot commented Jun 27, 2026

Copy link
Copy Markdown

Open in StackBlitz

npm i https://pkg.pr.new/@opennextjs/cloudflare@35

commit: d1b99ee

@devin-ai-integration devin-ai-integration Bot 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.

Devin Review found 3 potential issues.

Open in Devin Review

Comment thread packages/cloudflare/src/cli/adapter.ts
Comment thread packages/core/src/build/adapter.ts
Comment thread packages/cloudflare/src/api/config.ts Outdated
…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) => {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

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.

Comment on lines +157 to +158
fs.copyFileSync(cache.cache, path.join(tempCachePath, "cache.cjs"));
fs.copyFileSync(cache.composableCache, path.join(tempCachePath, "composable-cache.cjs"));

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

couldnt these also be mjs files?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

shouldnt the ext be based on the ext of the original filename?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

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");

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

is there a reason we're using console.log in here instead of our own logger fns?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Nope, I just forgot about it 😄

Comment on lines +200 to +202
const { useTagCache } = createCacheAssets(buildOpts);
console.log("Cache assets created");
if (useTagCache) {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

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"],

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

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?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

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({

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

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?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I guess I could give it a try yeah

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