refactor: split platform-specific code into platform-vercel and platform-cloudflare packages by ovflowd · Pull Request #8838 · nodejs/nodejs.org

ovflowd · 2026-04-23T02:12:30Z

Extracts all Vercel- and Cloudflare-specific integrations out of apps/site and into dedicated workspace packages (@node-core/platform-vercel, @node-core/platform-cloudflare), selected at build time via NEXT_PUBLIC_DEPLOY_TARGET (set by vercel.json and the OpenNext buildCommand).

Each adapter exports a next.platform.config.mjs with a { nextConfig, aliases, images, mdx } shape that apps/site merges into its Next.js config, MDX plugins, and Playwright config via dynamic import. No-op apps/site/next.platform.config.mjs and apps/site/playwright.platform.config.mjs keep standalone pnpm dev / pnpm build / pnpm deploy working when no target is set.

Removes the last platform forks from apps/site — VERCEL_ENV, OPEN_NEXT_CLOUDFLARE, 'Cloudflare' in global, and PLAYWRIGHT_RUN_CLOUDFLARE_PREVIEW are all gone.

vercel · 2026-04-23T02:12:35Z

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

Project	Deployment	Actions	Updated (UTC)
nodejs-org	Ready	Preview	Apr 25, 2026 9:21pm

github-actions · 2026-04-23T02:12:42Z

👋 Codeowner Review Request

The following codeowners have been identified for the changed files:

Team reviewers: @nodejs/web-infra @nodejs/nodejs-website

Please review the changes when you have a chance. Thank you! 🙏

codecov · 2026-04-23T02:14:32Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.89%. Comparing base (620b605) to head (53b1ce5).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8838      +/-   ##
==========================================
+ Coverage   73.81%   73.89%   +0.07%     
==========================================
  Files         105      105              
  Lines        8883     8882       -1     
  Branches      327      324       -3     
==========================================
+ Hits         6557     6563       +6     
+ Misses       2325     2318       -7     
  Partials        1        1

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

ovflowd · 2026-04-23T02:15:00Z

FYI deployment will only work once this gets merged as we need to change the root directory within vercel.

avivkeller

Really really against the symlinks, so blocking on that regard

ovflowd · 2026-04-23T11:12:49Z

Really really against the symlinks, so blocking on that regard

Why so? And what are your alternatives? Because Im unsure if there are any... Without duplicating every file 😅

ovflowd · 2026-04-23T11:14:24Z

Aviv, this PR is a PoC no need to go super nitpicky on it. I haven't done myself a round of reviews yet as I just published this PR so we can start analyzing approaches, I might as well convert to a draft.

avivkeller · 2026-04-23T11:31:24Z

Aviv, this PR is a PoC no need to go super nitpicky on it. I haven't done myself a round of reviews yet as I just published this PR so we can start analyzing approaches, I might as well convert to a draft.

Noted, I've converted it to a draft so it's clearer for reviewers

avivkeller · 2026-04-23T11:32:56Z

Why so? And what are your alternatives?

I'm not sure what the alternatives are, but Symlinks are a, in my opinion, slippery slope of inconsistent behavior across operating systems and build tools. Is there a way to tell Next.js / OpenNext to look at apps/site/ for the actual site, or something?

ovflowd · 2026-04-23T14:06:18Z

Why so? And what are your alternatives?

I'm not sure what the alternatives are, but Symlinks are a, in my opinion, slippery slope of inconsistent behavior across operating systems and build tools. Is there a way to tell Next.js / OpenNext to look at apps/site/ for the actual site, or something?

I'm investigating 👀

Platform detection in apps/site was spread across three different mechanisms: `VERCEL_ENV`, `OPEN_NEXT_CLOUDFLARE`, and a runtime `'Cloudflare' in global` check in the MDX plugin. Each one carried its own caveats (the global check blocked tree-shaking; the two env vars couldn't be compared to "is this build neutral / Vercel / Cloudflare?" uniformly), and Vercel analytics were imported eagerly in the root layout even on Cloudflare builds. Replace all three with a single `NEXT_PUBLIC_DEPLOY_TARGET` env var set by each deployment wrapper (`vercel.json` -> `vercel`, `open-next.config.ts` -> `cloudflare`). The `NEXT_PUBLIC_` prefix lets Next.js inline the value at build time so platform-specific branches are dead-code-eliminated from non-matching bundles. Extract the Vercel Analytics + SpeedInsights injection into a `platform/body-end` slot. The core layout renders `<BodyEnd />` and the slot's dynamic import resolves only on Vercel builds, so the Vercel modules no longer ship to Cloudflare.

…orm-cloudflare packages Why: Upgrading Next.js or any Vercel dep was gated by OpenNext's compatibility window, platform-specific runtime branches (VERCEL_ENV, OPEN_NEXT_CLOUDFLARE, 'Cloudflare' in global) were scattered across the codebase, and apps/site carried deps that only one deployment used. This extracts all platform-specific integrations into dedicated workspace packages selected at build time via NEXT_PUBLIC_DEPLOY_TARGET: - @node-core/platform-vercel owns Vercel analytics, speed insights, and OTel instrumentation. - @node-core/platform-cloudflare owns the OpenNext config, Wrangler config, worker entrypoint (with Sentry), image loader, and the MDX flags needed to skip WASM/Twoslash on Cloudflare workers. Each adapter exports a next.platform.config.mjs with a { nextConfig, aliases, images, mdx } contract that apps/site merges into its Next.js config, MDX plugins, and Playwright config via dynamic import. A no-op apps/site/next.platform.config.mjs and apps/site/playwright.platform.config.mjs keep the standalone pnpm dev / pnpm build paths working when no target is set. Runtime platform detection (PLAYWRIGHT_RUN_CLOUDFLARE_PREVIEW, 'Cloudflare' in global, OPEN_NEXT_CLOUDFLARE branches) is replaced with NEXT_PUBLIC_DEPLOY_TARGET selection so the apps/site source tree has no platform conditionals left. Docs updated: docs/technologies.md documents the NEXT_PUBLIC_DEPLOY_TARGET contract; docs/cloudflare-build-and-deployment.md points at the new package paths; CODEOWNERS moved the Wrangler / OpenNext ownership to the new packages.

Why: Turbopack's `resolveAlias` treats absolute paths as server-relative (prepending `./`) and rejects them with "server relative imports are not implemented yet". The `fileURLToPath(new URL(...))` pattern produced absolute paths that broke the plain `pnpm build` CI job. Project-relative strings resolve correctly in both Turbopack and webpack.

Turbo's persistent-task output buffering swallows wrangler dev's readiness signal in CI, making Playwright's webServer probe time out at 180s even though the preview eventually comes up. Move the OpenNext build to a dedicated CI step so Playwright's webServer can invoke wrangler dev directly, keeping stdout attached to the CI log and removing the dependsOn chain indirection.

wrangler's bin is hoisted to apps/cloudflare/node_modules/.bin under pnpm, not repo-root node_modules/.bin, so the previous direct path failed with ENOENT in CI. Delegating to the package script via `pnpm --filter` resolves wrangler from the right workspace and keeps stdout attached (no turbo buffering).

dario-piotrowicz

I appreciate where the PR is coming from, however I don't think I am a huge fan of this, having 3 apps being cloudflare, vercel and site seems quite unclear and unintuitive to me (since there is only a single app, site which can have 2 different variations). There are also magic build time resolutions that I feel are very likely to confuse and alienate people not too familiar with the codebase (and me 😅).

Sorry but personally I feel like, instead of making things clearer the changes here introduce clear/strong boundaries between the different versions of the site at the cost of making the project less clear and navigatable (and approachable by newcommers).

If it were me and we wanted to isolate the vercel and cloudflare logic using different packages in the monorepo I think I'd try to keep site being the only app and instead add cloudflare and vercel as actual packages instead and having site depend on those (with some minor exceptions such as wrangler and open-next config files).

Sorry this is my general take on the approach 😓

(PS: if people are happy with this I'll definitely won't try to spot this direction though 🙂)

Webpack bundles the top level of each platform's next.platform.config.mjs into the server output (because apps/site/mdx/plugins.mjs reads .mdx from it), which meant the Cloudflare build shipped `createRequire(...).resolve(...)` and `await getDeploymentId()` into the worker runtime — failing at request time with `m.resolve is not a function`. Moving the heavy, build-only pieces (`@opennextjs/cloudflare` imports, `require.resolve`, VERCEL_URL computation) behind async thunks keeps the module's top level free of Node-runtime-only code. Pair with the webpack `conditionNames` wiring so `#platform/*` actually resolves to the target variant at bundle time.

ovflowd · 2026-04-23T22:38:18Z

I'd try to keep site being the only app and instead add cloudflare and vercel as actual packages instead and having site depend on those (with some minor exceptions such as wrangler and open-next config files).

This is the exact opposite others asked. To be clear, apps/cloudflare and apps/vercel aren't "apps" or variations of the website, they are "packages", they are under "apps" because @avivkeller asked, as everything under "packages/" is supposed to be published. I'm fine making a new root folder named "platforms"

To also clarify here, @dario-piotrowicz, apps/site is the only package, all that happens is that when building for Vercel or for Cloudflare we tell Node.js to load the platform-specific config files and things that each one of these environments used.

dario-piotrowicz · 2026-04-23T23:21:06Z

This is the exact opposite others asked.

Oh ok... different people have different preferences 🙈

To be clear, apps/cloudflare and apps/vercel aren't "apps" or variations of the website, they are "packages", they are under "apps" because @avivkeller asked, as everything under "packages/" is supposed to be published. I'm fine making a new root folder named "platforms"

I see... yeah probably platforms would be clearer in my opinion 🤔 , although they are both tied to the site project (they don't make sense as standalone projects)... mh... I can't remember, in turborepo I think you can have packages inside packages... what about having Vercel and Cloudflare inside site/platforms/? (as standalone/isolated packages but inside the site directory)

To also clarify here, @dario-piotrowicz, apps/site is the only package, all that happens is that when building for Vercel or for Cloudflare we tell Node.js to load the platform-specific config files and things that each one of these environments used.

Yes I got that, but the dir structure really doesn't make it clear in my opinion, since site, cloudflare and vercel are sibling directories

… dir Replace `cd ../site && ...` in the three cloudflare scripts with `pnpm --filter=@node-core/website exec ...` so pnpm sets cwd transparently (per Dario's review feedback). Ignore apps/cloudflare/.wrangler, which is where wrangler v4 writes its state dir relative to the config file. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

ovflowd · 2026-04-23T23:26:53Z

I see... yeah probably platforms would be clearer in my opinion 🤔 , although they are both tied to the site project (they don't make sense as standalone projects)... mh... I can't remember, in turborepo I think you can have packages inside packages... what about having Vercel and Cloudflare inside site/platforms/? (as standalone/isolated packages but inside the site directory)

Im unsure how putting them as subfolders of apps/site makes things better. One of the goals here is that apps/site is the Next.js App, it is agnostic to any platform. But it is wired to support "platform" overrides, that's where the env flags come in, pretty much we're using Node.js to say "for cloudflare, please load the overrides that come from this apps/cloudflare" package. We aren't really building things within apps/cloudflare, nor apps/cloudflare is an actual app, I guess the name apps/ is the confusing factor. Think of apps/cloudflare or apps/vercel as bindings. Im fine moving them under another folder, but I'd like to avoid keep moving them around as @avivkeller said apps/ you said something else, so if we can reach an agreement of preference, that'd be great.

Yes I got that, but the dir structure really doesn't make it clear in my opinion, since site, cloudflare and vercel are sibling directories

I get that. Anyhow, the goal of this PR is to:

installing apps/site doesn't require any dep of apps/cloudflare or apps/vercel, so reduced deps, better control of blast radius, if smth breaks, it must be Next.js-related things or of our sandboxed app.
removes specific code and checks and paths and settings and logical statements regarding platforms. This makes hosting plain Next.js or static exports easier, also allows the codebase to grow to a number of different platforms.
Easier to group all code retaining a given platform. No more search across all packages;apps/site where we have Vercel or Clopudflare or Platform X-specific code, it is all in one place, easy to find and maintain.

dario-piotrowicz · 2026-04-24T11:57:55Z

Im unsure how putting them as subfolders of apps/site makes things better. One of the goals here is that apps/site is the Next.js App, it is agnostic to any platform. But it is wired to support "platform" overrides, that's where the env flags come in, pretty much we're using Node.js to say "for cloudflare, please load the overrides that come from this apps/cloudflare" package. We aren't really building things within apps/cloudflare, nor apps/cloudflare is an actual app, I guess the name apps/ is the confusing factor. Think of apps/cloudflare or apps/vercel as bindings. Im fine moving them under another folder, but I'd like to avoid keep moving them around as @avivkeller said apps/ you said something else, so if we can reach an agreement of preference, that'd be great.

Agreed 👍 , I do think that apps/ is a bit confusing here, but if everyone else is ok with it I'm ok with it as well (also the dir structure can be easy to change in the future anyways)

I get that. Anyhow, the goal of this PR is to:

installing apps/site doesn't require any dep of apps/cloudflare or apps/vercel, so reduced deps, better control of blast radius, if smth breaks, it must be Next.js-related things or of our sandboxed app.

removes specific code and checks and paths and settings and logical statements regarding platforms. This makes hosting plain Next.js or static exports easier, also allows the codebase to grow to a number of different platforms.

Easier to group all code retaining a given platform. No more search across all packages;apps/site where we have Vercel or Clopudflare or Platform X-specific code, it is all in one place, easy to find and maintain.

Yes and I don't disagree that it's doing that well. My concern here is that in order to satisfy those 3 goals the structure of the monorepo is becoming (at least in my opinion) more complex, less intuitive (and more unconventional?). So I think there is a tradeoff to be aware of between isolating the platforms bits and the complexity of the repo's setup.

This might also be subjective and people might not find the updated structure more complex 🤔

bmuenzenmeyer · 2026-04-24T12:08:50Z

In general, I'm in support of isolating the deployment targets from the rest of the code as best we can, and want to keep thinking about how best to do this. I suspect we need to put the branching logic somewhere, and I am thinking through the best options:

in config/scripts via /apps as the PR does
in new modules like /packages or /platforms

Naming things is hard, of course, and we are not constrained by the two monorepo directories we have now. Perhaps moving them to platforms/ helps ever so slightly. At the end of the day, the READMEs are doing the work.

So I think there is a tradeoff to be aware of between isolating the platforms bits and the complexity of the repo's setup.

I would agree with this in principle but also think this approach has made it simpler in a way to casual contribution.
I think the goal of being able to run the site locally and see mostly content, without any divergent platform code is admirable. The repo is already complicated. Made more so by learn, the api docs, the data we consume, i18n, I've said before I think that boat sailed a long time ago :D This IMO might be a net improvement, and I can imagine a step simpler to maintain if, say, a third deployment target were ever to present itself.

people might not find the updated structure more complex

Maybe yes, maybe no. Is it slightly unconventional? I think it's pushing the boundaries of how apps can be constructed. Most apps don't have the luxury? the design goal? of deploying multiple ways. But this feels like a good use of a monorepo and perhaps a slightly clever way to use import maps...but one that I see as innovative 😄

I do think we should always try to optimize for casual contribution, which I think this still does via a simpler /apps/site

bmuenzenmeyer

I am a 👍 on this proposal.
Due to the nature of the change, I wonder if we should bring this up in a web meeting?

Move apps/{vercel,cloudflare} to platforms/{vercel,cloudflare} and apps/site/vercel.json to platforms/vercel/vercel.json. Rebase all relative path references across workflows, CODEOWNERS, docs, and configs so tooling resolves from the new locations. vercel.json now declares outputDirectory (../../apps/site/.next) so Vercel can find the Next.js build when its Root Directory is set to platforms/vercel, and uses build.env for NEXT_PUBLIC_DEPLOY_TARGET and NODE_OPTIONS=--conditions=vercel instead of cross-env (which is not in the --prod install tree). Add NEXT_PUBLIC_DEPLOY_TARGET and NODE_OPTIONS=--conditions=cloudflare to the Cloudflare deploy workflow's build and deploy step env blocks so the outer opennextjs-cloudflare process resolves imports under the cloudflare condition (matching the Playwright workflow). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

The prior commit accidentally dropped this test during the directory rename rather than moving it alongside the other platforms/vercel files. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

ovflowd · 2026-04-24T22:00:15Z

@bmuenzenmeyer I made the changes for vercel.json, Vercel build will fail till I move change the appRoot within the UI.

avivkeller · 2026-04-25T21:01:39Z

-    registerOTel({ serviceName: 'nodejs-org' });
-  }
-}
+export { register } from '@platform/instrumentation';


Suggested change

export { register } from '@platform/instrumentation';

export { register } from '#platform/instrumentation';

Is the @ here intentional?

No, fixing, good catch!

avivkeller · 2026-04-25T21:04:19Z

This is the default, right? Maybe platforms/default?

Like in a new package? Is this really needed? 🤔 -- I wonder if it is implied default platform / apps/site, but I guess it makes sense?

avivkeller · 2026-04-25T21:07:55Z

 const openNextConfig: OpenNextConfig = {
  ...cloudflareConfig,
-  buildCommand: 'pnpm build --webpack',
+  buildCommand:


@dario-piotrowicz Suggestion for OpenNext: env for setting environment variables like this?

Sorry, can you clarify what you mean? 🙏

avivkeller · 2026-04-25T21:08:48Z

+    "./analytics": "./src/analytics.tsx",
+    "./image-loader": "./src/image-loader.ts",
+    "./instrumentation": "./src/instrumentation.ts",
+    "./next.platform.config": "./next.platform.config.mjs",
+    "./playwright.platform.config": "./playwright.platform.config.mjs",
+    "./worker-entrypoint": "./src/worker-entrypoint.ts"


Suggested change

"./analytics": "./src/analytics.tsx",

"./image-loader": "./src/image-loader.ts",

"./instrumentation": "./src/instrumentation.ts",

"./next.platform.config": "./next.platform.config.mjs",

"./playwright.platform.config": "./playwright.platform.config.mjs",

"./worker-entrypoint": "./src/worker-entrypoint.ts"

"./src/*": [

"./src/*",

"./src/*.ts",

"./src/*.tsx",

"./src/*.mjs"

]

Yeah, I was going to do that, also noticed this on self-review xD

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 53b1ce5. Configure here.}

cursor · 2026-04-25T21:26:07Z

+platforms/cloudflare/open-next.config.ts @nodejs/web-infra
+platforms/cloudflare/next.platform.config.mjs @nodejs/web-infra
+platforms/vercel/vercel.json @nodejs/web-infra
+platforms/vercel/next.platform.config.mjs @nodejs/web-infra


CODEOWNERS has duplicate redirects.json ownership entry

Low Severity

After the new platform entries were inserted, apps/site/redirects.json @nodejs/web-infra appears on both line 28 and line 35. The second entry is redundant. While CODEOWNERS silently handles duplicates (last match wins for the same path), the duplication suggests the original line wasn't noticed when the new platform lines were added between the two occurrences.

^{Reviewed by Cursor Bugbot for commit 53b1ce5. Configure here.}

dario-piotrowicz

This feels much better than the version I reviewed last, thanks for all the improvements @ovflowd! 🫶

I also completely agree with @bmuenzenmeyer this simplifying the base app and allowing contributors to just work on it without caring about target platform details is a very strong plus of this approach 🚀

Looks good to me, awesome work 🫶

dario-piotrowicz · 2026-04-25T22:18:07Z

+    "cloudflare:build:worker": "pnpm --filter=@node-core/website exec opennextjs-cloudflare build --openNextConfigPath ../../platforms/cloudflare/open-next.config.ts --config ../../platforms/cloudflare/wrangler.jsonc",
+    "cloudflare:deploy": "pnpm --filter=@node-core/website exec opennextjs-cloudflare deploy --openNextConfigPath ../../platforms/cloudflare/open-next.config.ts --config ../../platforms/cloudflare/wrangler.jsonc",
+    "cloudflare:preview": "pnpm --filter=@node-core/website exec wrangler dev --config ../../platforms/cloudflare/wrangler.jsonc",


Nice scripts 🤩

What about getting rid of the cloudflare: prefix as well? (and also build's :worker suffix)?

dario-piotrowicz · 2026-04-25T22:20:17Z

@@ -0,0 +1 @@
+export const register = () => {};


Is this file actually needed?

dario-piotrowicz · 2026-04-25T22:48:33Z

+│   ├── vercel/                  # Vercel deployment adapter
+│   │                            #   (analytics, instrumentation, vercel.json)
+│   └── cloudflare/              # Cloudflare deployment adapter


These haven't been updated, they are no longer under apps

dario-piotrowicz · 2026-04-25T22:50:26Z

+    "url": "https://github.com/nodejs/nodejs.org",
+    "directory": "platforms/vercel"
+  },
+  "scripts": {


Should the vercel platform also have some build/deploy scripts?

Copilot AI review requested due to automatic review settings April 23, 2026 02:12

ovflowd requested review from a team as code owners April 23, 2026 02:12

This comment was marked as outdated.

Sign in to view

Copilot started reviewing on behalf of ovflowd April 23, 2026 02:12 View session

cursor Bot reviewed Apr 23, 2026

View reviewed changes

Comment thread apps/vercel/next.constants.mjs Outdated

Comment thread apps/vercel/turbo.json Outdated

Comment thread apps/vercel/turbo.json Outdated

This comment was marked as low quality.

Sign in to view

avivkeller requested changes Apr 23, 2026

View reviewed changes

avivkeller marked this pull request as draft April 23, 2026 11:30

ovflowd force-pushed the refactor/split-apps-by-deployment-target branch from 659dda2 to d7b6e7e Compare April 23, 2026 16:09

vercel Bot deployed to Preview April 23, 2026 16:10 View deployment

ovflowd changed the title ~~refactor: split site into site/vercel/cloudflare apps~~ refactor: unify platform detection via NEXT_PUBLIC_DEPLOY_TARGET Apr 23, 2026

vercel Bot deployed to Preview April 23, 2026 17:44 View deployment

ovflowd changed the title ~~refactor: unify platform detection via NEXT_PUBLIC_DEPLOY_TARGET~~ refactor: split platform-specific code into platform-vercel and platform-cloudflare packages Apr 23, 2026

ovflowd requested a review from avivkeller April 23, 2026 17:45

ovflowd marked this pull request as ready for review April 23, 2026 17:45

Merge branch 'main' into refactor/split-apps-by-deployment-target

c88bfc5

vercel Bot deployed to Preview April 23, 2026 17:46 View deployment

ovflowd requested a review from avivkeller April 23, 2026 21:25

vercel Bot deployed to Preview April 23, 2026 21:26 View deployment

cursor Bot reviewed Apr 23, 2026

View reviewed changes

Comment thread apps/site/next.constants.mjs

Comment thread apps/site/mdx/plugins.mjs

vercel Bot deployed to Preview April 23, 2026 21:45 View deployment

vercel Bot deployed to Preview April 23, 2026 21:49 View deployment

dario-piotrowicz reviewed Apr 23, 2026

View reviewed changes

Comment thread apps/cloudflare/package.json Outdated

vercel Bot deployed to Preview April 23, 2026 22:26 View deployment

vercel Bot deployed to Preview April 23, 2026 23:28 View deployment

ovflowd requested a review from dario-piotrowicz April 23, 2026 23:30

cursor Bot reviewed Apr 23, 2026

View reviewed changes

Comment thread .github/workflows/tmp-cloudflare-open-next-deploy.yml Outdated

bmuenzenmeyer approved these changes Apr 24, 2026

View reviewed changes

Comment thread .github/CODEOWNERS

Comment thread platforms/cloudflare/src/image-loader.ts

Comment thread platforms/vercel/vercel.json

ovflowd and others added 2 commits April 24, 2026 18:55

fix(platform): restore platform-vercel next config test under platforms/

68b5524

The prior commit accidentally dropped this test during the directory rename rather than moving it alongside the other platforms/vercel files. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

vercel Bot deployed to Preview April 24, 2026 22:01 View deployment

cursor Bot reviewed Apr 24, 2026

View reviewed changes

Comment thread platforms/vercel/next.platform.config.mjs

avivkeller reviewed Apr 25, 2026

View reviewed changes

Merge branch 'main' into refactor/split-apps-by-deployment-target

53b1ce5

vercel Bot deployed to Preview April 25, 2026 21:21 View deployment

cursor Bot reviewed Apr 25, 2026

View reviewed changes

dario-piotrowicz approved these changes Apr 25, 2026

View reviewed changes

	export { register } from '@platform/instrumentation';
	export { register } from '#platform/instrumentation';

Conversation

ovflowd commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vercel Bot commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as outdated.

github-actions Bot commented Apr 23, 2026

👋 Codeowner Review Request

Uh oh!

codecov Bot commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

ovflowd commented Apr 23, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment was marked as low quality.

Uh oh!

avivkeller left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ovflowd commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ovflowd commented Apr 23, 2026

Uh oh!

avivkeller commented Apr 23, 2026

Uh oh!

avivkeller commented Apr 23, 2026

Uh oh!

ovflowd commented Apr 23, 2026

Uh oh!

Uh oh!

Uh oh!

dario-piotrowicz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ovflowd commented Apr 23, 2026

Uh oh!

dario-piotrowicz commented Apr 23, 2026

Uh oh!

ovflowd commented Apr 23, 2026

Uh oh!

Uh oh!

dario-piotrowicz commented Apr 24, 2026

Uh oh!

bmuenzenmeyer commented Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bmuenzenmeyer left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ovflowd commented Apr 24, 2026

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

ovflowd commented Apr 23, 2026 •

edited

Loading

vercel Bot commented Apr 23, 2026 •

edited

Loading

codecov Bot commented Apr 23, 2026 •

edited

Loading

ovflowd commented Apr 23, 2026 •

edited

Loading

bmuenzenmeyer commented Apr 24, 2026 •

edited

Loading

CODEOWNERS has duplicate `redirects.json` ownership entry