question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

assetPrefix not working on getStaticProps JSON

See original GitHub issue

Bug report

Describe the bug

When using getStaticProps with assetPrefix, the JSON file with the page data is not using assetPrefix.

Current: https://domain-name.com/_next/data/${build_id}/es/cars/audi.json Expected: https://cdn-name.com/_next/data/${build_id}/es/cars/audi.json

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

  1. Set assetPrefix on next.config.js
  2. Create a page that uses getStaticProps
  3. Navigate to that page using Link or Router
  4. Open the devTools console
  5. See that the requested JSON uses the hostname instead of the assetPrefix

Expected behavior

Use assetPrefix on getStaticProps JSON

System information

  • OS: Ubuntu 18.04.4 LTS
  • Browser: Chrome 84
  • Version of Next.js: 9.5.2
  • Vercel production build

Additional info

Similar closed/fixed issues: #11992 & #15287

The answer given for the issue #11992 is not working in our case because we want to use a subdomain and this is not supported on basePath:

Please use the new basePath support instead of assetPrefix in Next.js 9.5.1+ for this use case!

_Originally posted by @Timer in https://github.com/vercel/next.js/issues/11992#issuecomment-666148936_

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Reactions:12
  • Comments:12 (3 by maintainers)

github_iconTop GitHub Comments

10reactions
jayeheffernancommented, Nov 14, 2020

Hi everyone!

I understand that this is intended behaviour but it’s a big issue with deploying a site I’m working on. I’d love to see it addressed, probably in the form of a new config variable (to not make any breaking changes). I’m looking for a solution for the situation where a user has already loaded a page, and we make a deploy while they’re in the middle of using it. Our deploy system is “atomic”, so any files that changed names for the deploy will now be missing on the main domain (from the perspective of the stale page in the user’s browser). I thought I had a good solution to this, but it’s blocked by this issue.

I’ll describe my situation on Netlify, but it seems this is also an issue on the Vercel platform.

The problem

Users load our page through the main domain, but each Netlify deploy also gets its own unique deploy URL. This means that the deployed assets, bundles etc. from any previous deploy remain accessible. So my idea is that I should be able to use the unique URL to allow a user to continue browsing the site with whatever version of the page they have loaded: all further requests from the Next.js app client-side for assets, new bundles, etc. should be served from the deploy URL that they loaded. If they reload the page, the latest deploy URL will be included in the new response, and they will browse that version from then on.

What I’ve tried

To get this working I have tried setting Next.js’s assetPrefix and webpack’s output.publicPath to the unique deploy URL. This almost works great. Whatever deploy is the one to serve the initial page load to the user, the images and bundles are loaded from that unique deploy URL. This way the user can continue to browse around the site and their pages and assets will continue to load. Great!

Why it doesn’t work

What ruins this whole plan is (from the docs):

Asset prefix support does not influence the following paths: […] /_next/data/ requests for getStaticProps pages. These requests will always be made against the main domain to support Incremental Static Generation, even if you’re not using it (for consistency).

From my understanding this means that the props returned from getStaticProps() will always be served from the main domain, even if my page bundles have been loaded from an older deploy. Those props can be very important (e.g. we set a lot of data from the CMS through those props), and it will often be the case that an updated page component is not compatible with the getStaticProps() result of a previous deploy. So our page components will be out of sync with the data passed to render them, if we are not able to to apply assetPrefix (or some equivalent) to these paths.

What else I’ve considered

I’ve noticed on other issues (e.g. #11992) that basePath is a newer config parameter that is suitable for some use-cases people were trying to use assetPrefix, but it does not appear to be a good fit for this. It can’t be set to an absolute URL, and if it could then <Link />s would presumably start linking off to some other domain.

The other solution I’ve seen is to use a service worker to force the user to refresh, or to prompt them that there is a new version of the site. Apart from the added complexity to figure out how to properly configure the service worker, this is also not good UX. A site cannot always force a reload of the user’s page, because they might be in the middle of reading, interacting, filling in a form, or making a purchase. To prompt the user to refresh because there is a new version of the page available might be ok for more of an “app”-style site, but for something like an ecommerce site it would be a very strange and off-putting experience for the user to have to interact with that. If the site is being actively developed there may be multiple deploys per day, which means annoying and confusing the user multiple times per day with this method.

My issue could also be mostly fixed on a platform level, by keeping files from old deploys available through the CDN on the main domain. This wouldn’t be possible if the files don’t change name, but maybe with content-hashes it could work. I don’t think Next.js should rely on platform support for this though, and it’s currently not implemented for either Netlify or Vercel.

Please help

Please reconsider allowing assetPrefix (or some other variation) to configure what domain /_next/data/ requests are served on 🙏 It will be a great help for many developers who want to actually run Next.js in production and serve their site to a lot of users.

5reactions
GxDesigncommented, Nov 14, 2020

Our team is experiencing this exact issue as well with Vercel production builds, all browsers, NextJS 9.5.3-canary.10

Read more comments on GitHub >

github_iconTop Results From Across the Web

Data Fetching: getStaticProps - Next.js
Fetch data and generate static pages with `getStaticProps`. ... function — it will not work if you add getStaticProps as a property of...
Read more >
Fetch error when building Next.js static website in production
I use getStaticProps and getStaticPath fetch from an API route. First when I npm run build FetchError: invalid json response body at https:// ......
Read more >
Next.js (useStaticProps, useStaticPaths) + Static JSON Data
getStaticProps - Data is fetched during build time and is available before any client request. getStaticPaths - Data is fetched using dynamic routes....
Read more >
Fixing next.js export path to assets issue - Andrew Zakordonets
The problem was that all static assets were linked in html under /_next/static/ folder path. After quite some googling and try outs I ......
Read more >
Next.js: The Good, Bad and Ugly - An Idiosyncratic Blog
Issues with Next.js; CSS Modules; Automatic Static Optimization, ... as static HTML + JSON (uses getStaticProps) (ISR) incremental static ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found