Replies: 2 comments 4 replies
|
Hi @mjarosch, This happens because when the external service dynamically rewrites your relative Since you cannot use relative paths because the service refuses to host the files, you should force Next.js to generate absolute URLs natively during the build process, rather than relying on the scraping service to rewrite them on the fly. You can fix this by setting the Here is how you can configure it: // next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
// Replace with your actual root domain where the assets are hosted
assetPrefix: 'https://your-domain.com',
// Since the service uses a subdomain, you might also need to configure CORS
// to allow the subdomain to fetch the JS chunks from your root domain.
async headers() {
return [
{
source: '/_next/:path*',
headers: [
{ key: 'Access-Control-Allow-Origin', value: '*' }, // Or restrict it to the specific subdomain
],
},
];
},
}
module.exports = nextConfig |
|
I would prefer not to add the asset prefix, since we are a content site and host multiple sites with the single codebase. Is there another option to support this without the prefix? |
|
Gotcha @mjarosch! A static assetPrefix definitely won't work for a multi-tenant setup. The issue is that Turbopack dynamically injects new <script> tags on the client. Since the runtime executes on the scraper's subdomain, it tries to fetch lazy-loaded /_next/ chunks from there instead of your origin, causing the 404s. Here are two ways to handle this dynamically without next.config.js:
import { headers } from 'next/headers';
export default function RootLayout({ children }) {
const tenantDomain = `https://${headers().get('host')}`;
return (
<html>
<head>
<base href={tenantDomain} />
</head>
<body>{children}</body>
</html>
);
}This also affects relative and
import { headers } from 'next/headers';
export default function RootLayout({ children }) {
const tenantDomain = `https://${headers().get('host')}`;
return (
<html>
<head>
<script
dangerouslySetInnerHTML={{
__html: `
(function() {
const originalAppend = document.head.appendChild;
document.head.appendChild = function(child) {
if (child.tagName === 'SCRIPT' && child.src) {
try {
const url = new URL(child.src, window.location.origin);
if (url.origin === window.location.origin && url.pathname.startsWith('/_next/')) {
child.src = '${tenantDomain}' + url.pathname + url.search;
}
} catch (e) {}
}
return originalAppend.call(this, child);
};
})();
`,
}}
/>
</head>
<body>{children}</body>
</html>
);
}Just make sure your origin servers have the correct CORS headers so the scraper's subdomain is allowed to fetch the chunks |
|
@mohibali07 the base tag is the right instinct and it holds up against the runtime source. Two notes on the details though, because option 2 reintroduces the exact bug being fixed here. Option 2 puts the absolute URL back in the attributeThat is the failure mode, not a workaround for it. Rewriting Once the injected chunk executes, return { src: chunk.getAttribute('src')! } as CurrentScriptand that string lands in const path = src.startsWith(CHUNK_BASE_PATH)
? src.slice(CHUNK_BASE_PATH.length)
: src
There is a second, quieter effect. const previousScripts = document.querySelectorAll(
`script[src="${chunkUrl}"],script[src^="${chunkUrl}?"],script[src="${decodedChunkUrl}"],script[src^="${decodedChunkUrl}?"]`
)
The base tag avoids both because it never touches the attribute. The runtime keeps reading a relative string, the browser resolves it against the base, and the two stay consistent. Option 1 probably does not need
|
|
Great catch! Thank you for diving into the Turbopack source code for this. You are absolutely right on both points. Option 2 is definitely busted here. I completely missed how getPathFromScript and doLoadChunk rely on the literal, relative attribute string for chunk registration and deduplication. Modifying the src attribute on the fly directly re-introduces the exact bug. I stand corrected! You're spot on about headers() in Option 1. Using a dynamic header not only unnecessarily opts the layout into dynamic rendering (killing the cache), but the Host header would just return the scraper's server anyway, not the visitor's subdomain. So @mjarosch, ignore my second option! As pointed out, the absolute cleanest and most performant workaround is just a static tag, which avoids interfering with the Turbopack runtime entirely: export default function RootLayout({ children }) {
return (
<html>
<head>
{/* Resolves all relative asset requests to your actual root domain */}
<base href="https://your-root-domain.com/" />
</head>
<body>{children}</body>
</html>
);
}just ensure your origin's CORS headers allow the scraper's subdomain to access /_next/static/* |
|
@mjarosch you asked for an option that does not need the prefix. There is one. The reason it works also pins down the exact failure you are hitting, so it is worth going through both. What is actually breakingI read the Turbopack browser runtime at the
return { src: chunk.getAttribute('src')! } as CurrentScriptThat raw string goes straight into const chunkUrl = chunkScript.src!
const src = decodeURIComponent(chunkUrl.replace(/[?#].*$/, ''))
const path = src.startsWith(CHUNK_BASE_PATH)
? src.slice(CHUNK_BASE_PATH.length)
: src
return path as ChunkPath | ChunkListPath
The throw new Error('chunk path empty but not in a worker')Your second error message, from the same function, four lines up from the one that normally handles it. The option that avoids assetPrefixAsk the service to inject a base element and stop rewriting the <base href="https://your-root-domain.com/">Leave every This works because the runtime and the browser read two different values off the same tag. The runtime keys everything on Lazy chunks stay consistent for the same reason. For a content site running many domains off one codebase, that difference is the whole point. A base element is per document, so one build serves every site and each site's HTML names whatever origin is serving it. Two caveatsThe service has to cooperate. If they rewrite A base href governs every relative URL on the page, not just scripts. Relative links, images and form actions all begin resolving against the root domain too. For a content site that is usually the behaviour you want, but audit it before shipping rather than after. I have not run this. The mechanism is read out of the v16.2.4 source, not reproduced against your setup, so treat it as a grounded hypothesis rather than a tested fix. If it misbehaves, the first thing I would look at is what (Rewrote this comment after re-reading the thread. My first version pushed |
Uh oh!
There was an error while loading. Please reload this page.
Summary
We have a service we use that scrapes our site and wraps their content in our frame. They use a subdomain, so all script
srcattributes are changed from relative to absolute with the root domain. The startup silently fails, so none of the interactive elements work.The
registerChunkmethod in the turbopack file silently fails on this line:if (await Promise.all(r.otherChunks.map(e => T(i.Runtime, n, e))),This is a NextJS 16.2.4 app. The line works perfectly fine when using a relative
srcattribute.If I add a
type="module"to the script tag, it doesn't fail on that line, but gives the following err:Any suggestions for how I can work around this? The service doesn't want to host the files, so a relative
srcattribute is out.Additional information
No response
Example
No response
All reactions