fix: sitemap url for production deployments #5599
Conversation
https://twitter.com/mayankistyping/status/1686288768326914048 Signed-off-by: Steven <steven@ceriously.com>
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
📦 Next.js Bundle Analysis for nodejs.orgThis analysis was generated by the Next.js Bundle Analysis action. 🤖
|
| Page | Size (compressed) |
|---|---|
global |
140.88 KB (6 B) |
Details
The global bundle is the javascript bundle that loads alongside every page. It is in its own category because its impact is much higher - an increase to its size means that every page on your website loads slower, and a decrease means every page loads faster.
Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis
If you want further insight into what is behind the changes, give @next/bundle-analyzer a try!
Two Pages Changed Size
The following pages changed size from the code in this PR compared to its base branch:
| Page | Size (compressed) | First Load |
|---|---|---|
/404 |
34.41 KB (🟢 -22 B) |
175.28 KB |
/[...path] |
34.34 KB (🟢 -22 B) |
175.21 KB |
Details
Only the gzipped size is provided here based on an expert tip.
First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.
Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis
Next to the size is how much the size has increased or decreased compared with the base branch of this PR. If this percentage has increased by undefined% or more, there will be a red status indicator applied, indicating that special attention should be given to this.
Unit Test Coverage Report
Unit Test Report
|
|
I agree that this appears to be a production bug - but not knowing the status of the env var or having access to vercel, I'd rather @ovflowd merge it in the morning |
|
Yup that's right! Deploying now :) PS: I didn't merge back then because I was already going to sleep! |
|
@ovflowd Did you set the env var yet? I’m still seeing the bug on the latest deployment. |
|
Of course I dit. And it was working when I made the deployment. Now when I open this (https://nodejs.org/sitemap.xml), it seems gone. Is Vercel applying my Env Variables to the Serverless Functions? I have no idea why it would work then stop working. |
|
|
|
Triggering a redeployment. What is even weirder is that the URL on the current sitemap, is coming from a Preview Deployment? (nodejs-lp1va9y4q)
|
That sounds like its the issue. If you promoted a Preview deployment, then it wouldn't get Production env vars. |
To clarify, we never promoted any "preview" build to production. We use default settings. Only "main" branch should go to "production". Is this by any chance a bug on Vercel-side? |
|
It's fixed now, but pretty much because I did a "rebuild" of a production build. And this seems to be a thing that is recurring (from time to time these .vercel.app URLs from preview deployments seem to somehow get there) Could aos by any chance Turborepo Cache be influencing here? |
|
Ah yes it could be turborepo cache. The deployment from PR #5595 would be considered Preview and then once merged, since there were no code changes, you might see "FULL TURBO" in the Production build logs meaning it would just reuse the built output from the PR. You might want to add all the env vars you depend on to the I'll ask the turborepo team if they have any better suggestions. |
|
This is definitely relevant knowledge, right there! (Thank you @styfle !!) |
|
Hot-fix: 97821bc |
|
@ovflowd I spoke to the turborepo team and they said this is the expected behavior because default is "loose" env var handling. Adding the env vars like you did is a good solution 👍 If you wanted to catch this type of bug in the future, you could enable "strict" env var handling, which would prevent any env var from being used without explicitly marking it as part of the cache key hash or marking it as a pass-through. |
|
Thanks @styfle! Would you be kind enough and make a PR for strict env? 🙇 |
|
I have't tried it yet, so I'll have to update my own repos before this one 😆 |
|
Np! If you prefer I can handle the PR. |
Description
The sitemap for production deployments point to the wrong url.
You can see this by visiting https://nodejs.org/sitemap.xml
Validation
You'll need to set the
NEXT_PUBLIC_BASE_URLenv var and then visit/sitemap.xmlto see the impact.You can set the env var in the Vercel dashboard and redeploy, or you can try it locally via
next devby creating.env.local.Related Issues
https://twitter.com/mayankistyping/status/1686288768326914048
Check List
npx turbo lintto ensure the code follows the style guide. And runnpx turbo lint:fixto fix the style errors if necessary.npx turbo formatto ensure the code follows the style guide.npx turbo testto check if all tests are passing, and/ornpx turbo test:snapshotto update snapshots if I created and/or updated React Components.