cc @jxnblk

cc @alexindigo @DullReferenceException

Would love to have your feedback 👍

After playing with the code I realized that it would be much easier to split assetPrefix into multiple parts:

module.exports = {
  host: NOW_URL ? `https://${alias}` : 'http://localhost:3000',
  basePath: '/account',
}

We can still keep the assetPrefix variable internaly, but the user should define more precisely what he needs.

For the asset part is really ok to provide these two variables together.
For routing etc we need them separately.
Or maybe we can even provide it together in a config file and then split it in the next.js codebase. In this case assetPrefix is not the right name I am afraid.

As a sideffect this also leads to less code changes.
It's quite obvious if you compare those two PRs:
https://github.com/panter/next.js/pull/2 (split)
https://github.com/panter/next.js/pull/1 (pass both)

In my opinion, they should be separate, the reason for this is that it's not breaking and more flexible to keep assetPrefix and have basePath seperately.

Is assetPrefix the right name then? Both variables are actually a prefix right?

assetPrefix is for assets eg: the page bundles. basePath will be for the router.

The way it should work is:

• if assetPrefix is defined use assetPrefix to load bundles, don't touch the router (current behavior)
• if assetPrefix and basePath are provided use assetPrefix to load bundles, add basePath to router
• if assetPrefix is not defined and basePath is, use basePath to load bundles, and add basePath to router
• if neither assetPrefix nor basePath is defined we do nothing different (current behavior when assetPrefix is not provided)

cc @alexindigo @DullReferenceException @3rd-Eden

Could you give feedback on the above proposal: https://github.com/zeit/next.js/issues/4998#issuecomment-414978297

@tomaswitek Not sure what exactly didn't work for you with current assetPrefix, this is asset prefix we're using in production: "assetPrefix":"https://static.trulia-cdn.com/javascript" and it works as expected.

And in general, we're using multiple zones (we call them islands) on the same domain and "basePathing" each island never came to our minds, since it'd complicate interoperability between the islands. Let me elaborate on tat a little bit more:

So we have two islands A and B, and the main idea with it is transparency for the users that navigate island to island as part of their one-website experience. So there should be links between the islands. Then there is deployment concern vs. application concern.

1. Deployment concern vs. application concern – application has no idea where it could be deployed, it just know how to handle incoming http requests – it has set out routes it can respond to.
   When it's deployed somewhere – it could be different domains, different ports, and yes theoretically it could be different basePath, that will be made transparent for the app via proxy or other means.

2. Cross links between the islands – to keep the spirit of the islands as a separate deployable entities there shouldn't be any internal implementation knowledge leaks between different islands.
   So best way for islands to reference pages of each other, is for them to export available routes for other island(s) to consume (_and in the nextjs world it looks like custom <IslandALink> kind of components would be a preferred way_).
   So far it's all straight forward – all islands assume to share the same domain and have their set of absolute paths (/path1, path2, etc). That way second island imports that list of paths and relies on it to be stable. In the same time it's pretty minimal requirement for each island to keep their paths backward compatible (which is good thing in web anyway) :)

When we add deployment specific basePath, we automatically increase complexity of the whole system – should each island know (and maybe dictate) it's own deployment basePath? Then how is it different from the way thing work currently? Or should island A be agnostic of it's deployment path? Then how island B will find deployed island A, since it only knows what island A knows about itself? Or you'd have to supply basePath for all the deployed island to all other islands? And with modern way off deploying things, it means redeploying all the islands when you need to add new one.

Or how you envisioned that part of the story?

Thank you.

^ it was written before morning coffee, so please let me know if you need more coherent explanation for any parts of it. :)

First of all thank you guys that you took the time for reviewing my issue.

@timneutkens Yes assetPrefix has priority over basePath, that is exactly what we've discussed at the beginning. After I saw how many files I had to change I thought the second way would be cleaner. But I'll rollback to the first solution. Let's keep it totally separate, no problem at all. I was just loudly thinking.

@alexindigo Thx for your detailed answer. Let me try to answer your questions 😏

Not sure what exactly didn't work for you with current assetPrefix

I have two problems here:

1. I can't work with multiple domains nor subdomains in the current project. (Domain restrictions and no wildcard SSL certificate)
2. The current implementation of assetPrefix on a single domain requires more adjustments in proxy routing, static files etc. We could reduce this adjustments by introducing basePath. It won't brake anything and it won't increase complexity because you don't have to provide the basePath as @timneutkens already mentioned.

application has no idea where it could be deployed

We have the same goal here of course! We are defining assetPrefixes dynamically in the current solution we have. It is provided via request headers by proxy.

Then how is it different from the way thing work currently?

Router will be aware of contextPath and will reduce the amount of custom code.

should each island know (and maybe dictate) it's own deployment basePath? Or should island A be agnostic of it's deployment path?

It doesn't have to be. The developer should have freedom here. It should be possible to provide basePath dynamically the same way as assetPrefix.

Then how island B will find deployed island A, since it only knows what island A knows about itself? Or you'd have to supply basePath for all the deployed island to all other islands? And with modern way off deploying things, it means redeploying all the islands when you need to add new one.

Maybe you could also add the basePath into the routes export. I don't know. I am not saying that the basePath variable is important for every use case. It looks like it's not the best solution for you. But that's totally fine. The thing is that you can still use just assetPrefix and nothing will change for your islands. It looks like you have your own routing anyway. Cross links between zones is not even important for our project, our zones are really independent and isolated from each other.

And with modern way off deploying things, it means redeploying all the islands when you need to add new one.

I don't see a reason why. I can even imagine that some zones have basePaths and some not. And maybe some apps will use the basePath config even without multi zones setup.

@alexindigo could you pls provide us with a two real island urls, which are rendered by next.js so I could see it in action? I tried to find one, but could't find a page on your domain with _next requests 😄
Do all of your islands have the same configuration?
"assetPrefix":"https://static.trulia-cdn.com/javascript"

@tomaswitek

I can't work with multiple domains nor subdomains in the current project. (Domain restrictions and no wildcard SSL certificate)

Oh, so you don't use CDN in the classical sense, but rely on assets being fetched from each app directly? I see.

The current implementation of assetPrefix on a single domain requires more adjustments in proxy routing, static files etc. We could reduce this adjustments by introducing basePath. It won't brake anything and it won't increase complexity because you don't have to provide the basePath as @timneutkens already mentioned.

Btw, it wasn't "no, don't add that feature" :) It was more like – "Probably we can think about this approach more holistically" :)

It doesn't have to be. The developer should have freedom here. It should be possible to provide basePath dynamically the same way as assetPrefix.

Yes. It only works though when there is no linking between the islands. And sounds like this is your use case. In the same time, I'm having hard time understanding what makes them islands instead of just being a bunch of standalone applications then, if they're 100% independent? :)

Maybe you could also add the basePath into the routes export.

I don't se how it could be done (easily), since routes export happens at build time, and basePath being defined at deployment time, and there could be more than one deployment of the same code artifact (stage, preprod, prod, testing env, etc).

Do all of your islands have the same configuration?
"assetPrefix":"https://static.trulia-cdn.com/javascript"

Yes, all islands share their assets, since next does content hashing, it's not only non-issue, but actually very beneficial. (We extract built assets from each artifact and publish on CDN at deployment time).

And that way we have only "regular html" requests to our app servers, this is why I won't see any "_next" paths on trulia.com

As for the islands examples:

Our fresh brand new island – Neighborhoods page – https://www.trulia.com/n/ca/san-francisco/pacific-heights/81571 (and you can find more of them here: http://www.trulia.com/neighborhoods)
This island is responsible for all /n/* paths.

And another island is our login page – https://login.trulia.com/login – it looks like different domain, but it's really not, it looks that way for different set of reasons, but technically it's the same deployment. :)
And this island handles urls like /login, /signup.

Let me know if you have more questions.

@alexindigo thank you very much for your examples.
I have a few questions after anaylzing the examples 😄

You still do server rendering for every island, but you try to extract as much possibles assets into a common CDN right?

Can you pls describe a little bit more what exactly happens when https://www.trulia.com/n/ca/san-francisco/pacific-heights/81571 is called? Does your proxy know that /n stands for neighborhood overview and forwards it to the right island? Does it somehow affects the request before it arrives at the island?

Do you use built-in routing from next inside an island or do you have a custom solution?
I wanted to check the routing inside your island. Unfortunately Neighborhood overview has more or less just modal navigation without changing the url. In Login there seems to be a completely custom solution.

I hope I'll answer all your questions in this comment 😏

Btw, it wasn't "no, don't add that feature" :) It was more like – "Probably we can think about this approach more holistically" :)

Sure, it would be great to find a solution where I don't have to touch next.js 😏

Yes. It only works though when there is no linking between the islands. And sounds like this is your use case. In the same time, I'm having hard time understanding what makes them islands instead of just being a bunch of standalone applications then, if they're 100% independent? :)

I never wrote nor said that I search for an "island" solution. I just had a chat with @timneutkens where I described my problem and Tim's answer was basically next.js does not support basepaths. And after googling a little bit I realized I am not the only one searching for it. So I thought I could contribute a little bit. Afterwards Tim pinged you to give a me a feedback and I am very thankful for your feedback.

I don't se how it could be done (easily), since routes export happens at build time, and basePath being defined at deployment time, and there could be more than one deployment of the same code artifact (stage, preprod, prod, testing env, etc).

Well if you want to export routes at build time and make them available for other islands then the only straightforward way is probably to hardcode the basePath in the config. I get your point. On the other side, is that really such a problem? You could still deploy the app to different domains and ports and you could use the same basePath for each env.

Good morning @tomaswitek :)

My experience with the "basePath" functionality, that it very deceiving in it's complexity, and it's usually better to implement that kind of things without rushing into it with one specific problem,
but looking at it from multiple angles. Similar to how you'd approach deep merging – outline multiple use cases and see how (and if) they all fall under one umbrella. Since having incompatible features between (even major) versions of the framework is very annoying :)

You could still deploy the app to different domains and ports and you could use the same basePath for each env.

Sounds like you'd be ok with the solution where that "basePath" is part of your routing code, something that you mentioned in the beginning – like subfolder inside pages directory (btw, that approach would signal to developers chosen basePath pretty well). But the only thing that stopped you is that internal nextjs path for assets _next isn't configurable.

And that sounds like more narrow problem we can solve with less long term side effects.

And it could bring us even further, like if we can configure assetPath per asset (e.g. with next.config map of some sort) – it will allow us to have shared assets between the apps, which will improve performance, and other things.

And there is open PR for that feature. ;) /cc @timneutkens sounds like it's time to get back to that puppy. :)

If you're not going to add this any time soon, could we get an example express based server.js added to the readme that does this and works? I've tried a few that have been floating around in these issues but couldn't get them to work. Thanks.

Hi @ccarse I have a working fork which we use in production already: https://github.com/panter/next.js/pull/2
I am also ready to invest time to open a PR for this feature.
@timneutkens @alexindigo is there a other way how to solve this problem?
If we don't need a basePath config, can you pls give us a minimal example using assetPath?

My company is also coming up against this.

We're slowly taking over a legacy app, section by section, and replacing it with Next.js.

As a simplified example:

| URL | App |
|---|---|
| example.com | legacy |
| example.com/shop | next |
| example.com/search | legacy |
| example.com/members | next |

That means we want everything to be prefixed within each Next.js app... Pages, routes, assets, etc.

It's also worth noting that we're not using Now, so we cannot take advantage of now.json routing. We have our own load balancer sitting out in front of the whole domain and then routing traffic based on subpath.

We're also using a custom server (hapi), so it'd be nice if we could leverage whatever is create here within a custom server too.

Maybe there's some combination of now.config.json settings or some use of micro-proxy we can use to accomplish this same thing, but we haven't figured out the right combination yet.

We're running into, I think, the same problem with multiple statically exported Next.js apps hosted on Now v2.

| URL | App |
| - | - |
| example.com | next |
| example.com/dashboard | next |

As expected, the root app works just fine. Things go awry in the second one though. We're currently wrapping next/link which, combined with assetPrefix, solves most of the problem:

export default ({ children, href, ...rest }) => (
      <Link href={process.env.NODE_ENV === "production" ? `/dashboard${href}` : href} {...rest}>
        {children}
      </Link>
);

However, this breaks prefetch because then it tries to look for .js files at the wrong URL:

• Actual file URL: https://www.jirafe.io/dashboard/_next/static/Ya8O0iFjG~RJGGDYsrQ8S/pages/team/overview.js
• Prefetched file URL: https://www.jirafe.io/dashboard/_next/static/Ya8O0iFjG~RJGGDYsrQ8S/pages/dashboard/team/overview.js

Our current workaround is to disable prefetch, which isn't ideal.

What's the status on this?

Also looking for an update on this please.

@timneutkens I am ready to invest time to open a PR for it if the community is interested. We are already using a solution (https://github.com/panter/next.js/pull/1) in production and we are very happy with it.

We also need a solution for this

We're going to introduce a new API soon that will make this proposal obsolete.

Also impacted by this. Need to run the next project under a subdirectory path. Looking forward to the official feature. Is there an ETA?

API

So how is it going? :D

Please don't spam the thread and use GitHub's 👍 feature on the issue itself.

@timneutkens Can you provide any more info? What is the API that will make this obsolete? What do you consider "soon"? Thank you.

This may not be exactly related to multi-zones but may help...

I solved something similar to this by creating a custom server and using proxy middleware

for example: @Zertz
Please note: you still need to solve the link issue - Again, i solved this by creating a link component and passing the prefix down to the app via config and if a prefix exists use that or use nothing, same for static images.

const proxy = require('http-proxy-middleware');

app.setAssetPrefix('/dashboard');

  // Express custom server
  // Proxy so it works with prefix and without...
  // So if asset prefix is set then it still works
  const server = express();
  server.use(
    proxy('/dashboard', {
      target: 'http://localhost:3000', 
      changeOrigin: true,
      pathRewrite: {
        [`^/dashboard`]: '',
      },
    }),
  );

The proposal I was mentioning is #7329

The proposal I was mentioning is #7329

@timneutkens
Can you pls provide more details on how the proposed hook will solve our basepath problems?
And what about router redirects like Router.push('/about') will this be replaced with a hook as well?

Thank you for your time 😏

The router api would change too, as it'd need a component to link to. At that point you could use relative paths for the url itself.

Any update on when we can get a solution or at least a workaround for this?

Use 👍 on the initial issue instead of posting any update.

@MMT-LD Your solution kind of works for me, but now on every Link click or Router push event the page reloads ☹️

I tried @Zertz 's solution and it worked perfectly!
Also I could fix prefetch problem by copying output files to the prefetched paths.
https://github.com/fand/MDMT/blob/master/scripts/copy-preload.js

... it's a dirty trick, but it's working anyways🤪

@nicholasbraun

Now on every Link click or Router push event the page reloads ☹️

I had this issue but fixed using the 'as' parameter on the link, so the link points to the internal file, but the 'as' is relative to path
eg:
<Link href={"/${item.link}"} as={"./${item.link}"}>

@nicholasbraun

Your solution kind of works for me, but now on every Link click or Router push event the page reloads ☹️

This is kind of what i meant. This is from memory.... but im sure you cant get to what you need from the below.

// WithConfig component
import getConfig from 'next/config';

const { publicRuntimeConfig } = getConfig();

const WithConfig = ({ children }) =>
  children && children({ config: publicRuntimeConfig });

export default WithConfig;

// Extended Link component

 import React from 'react';
import PropTypes from 'prop-types';
import Link from 'next/link';
import { WithConfig } from '../WithConfig';
/* 
    <Link> component has two main props:
    href: the path inside pages directory + query string. e.g. /page/querystring?id=1
    as: the path that will be rendered in the browser URL bar. e.g. /page/querystring/1

*/

const NextLink = ({
  browserHref,
  pagesHref,
  whatever,
}) => {
  return (
    <WithConfig>
      {({ config: { pathPrefix } = {} }) => (
        <Link
          as={pathPrefix ? `${pathPrefix}${browserHref}` : browserHref}
          href={pagesHref}
          passHref
        >
          <a>{whatever}</a> // this bit is up to you - children or whatever
        </Link>
      )}
    </WithConfig>
  );
};

NextLink.propTypes = {
  browserHref: PropTypes.string.isRequired,
  pagesHref: PropTypes.string,
};

NextLink.defaultProps = {
  pagesHref: undefined,
};

export default NextLink;

Usage:

import NextLink from '../NextLink'

<NextLink browserHref={`/page/1`} pagesHref={`/page?querystring=1`} whatever='I'm the link' />

Good luck :smiley:

As the useLink RFC is now declined (#7329) and having basePath support would greatly help us, is the Next.js project happy to accept PRs implementing it? I'm willing to do it.

Looking at this implementation by @tomaswitek, it seems to be going in the right direction, most importantly making the router aware of basePath. Are there other non-obvious things that would make basePath support difficult?

Overall, I think that the design is clear, just a single config variable:

module.exports = {
  basePath: '/demo'
}

Interactions with assetPrefix are well-defined here: https://github.com/zeit/next.js/issues/4998#issuecomment-414978297.

UPDATE: I was also thinking whether it would be possible to implement this by creating a custom router and somehow swapping the default one but it doesn't seem to be possible, Next.js hardcodes its router, see e.g. here. I'm also skeptical that "only" replacing the router would be enough; the feature probably needs to be supported by Next.js as a whole.

This problem is around since 2017, is there any workaround? Or an official response to our basePath request?

So after trying to make this work with the combination of assetPrefix and a custom <Link> component as suggested in e.g. https://github.com/zeit/next.js/issues/4998#issuecomment-464345554 or https://github.com/zeit/next.js/issues/4998#issuecomment-521189412, I don't believe it can be done, unfortunately.

Defining assetPrefix was relatively straightforward, something like this in next.config.js:

const assetPrefix = process.env.DEPLOYMENT_BUILD ? '/subdir' : '';

module.exports = {
  assetPrefix,
  env: {
    ASSET_PREFIX: assetPrefix,
  },
}

The next step is a custom Link component. The first idea, given e.g. in https://github.com/zeit/next.js/issues/4998#issuecomment-464345554, is to prefix href like this (simplified):

export default ({ children, href, ...rest }) => (
  <Link href={`${process.env.ASSET_PREFIX}${href}`} {...rest}>
    {children}
  </Link>
);

As reported by others in this thread, this breaks prefetching as the requests are suddenly to /subdir/_next/static/.../pages/subdir/example.js – the other "subdir" should not be there. But with our custom Link component, we're setting href to /subdir/example, so no wonder Next.js is requesting a bundle of the pages/subdir/example.js page.

So OK, problematic prefetching doesn't sound like the end of the world (though the UX is quite ugly) but in our app, things get worse as we're using Next.js 9's dynamic routing. For that, we need to set as properly so the evolution of the custom Link component looks like this:

export default ({ children, href, as, ...rest }) => (
  <Link 
    href={`${process.env.ASSET_PREFIX}${href}`}
    as={`${process.env.ASSET_PREFIX}${as}`}
    {...rest}
  >
    {children}
  </Link>
);

Usage is:

<CustomLink href='/post/[id]' as='/post/1'>...</CustomLink>

which gets converted to:

<Link href='/subdir/post/[id]' as='/subdir/post/1'>...</Link>

and that was not working for me when deployed on Now at all – trying to navigate to https://deployment-id.now.sh/subdir/post/1 lead to 404. I'm not entirely sure why, maybe it's also an issue with @now/next builder (UPDATE: it's because of https://github.com/zeit/next.js/pull/8426#issuecomment-522801831) but ultimately, we're confusing Next.js' router when we're asking for /subdir/post/[id] component when no such file exists on the disk.

There's another example in this thread, https://github.com/zeit/next.js/issues/4998#issuecomment-521189412, that prefixes only as, not href, like this (simplified):

export default ({ children, href, as, ...rest }) => (
  <Link href={href} as={`${process.env.ASSET_PREFIX}${as}`} {...rest}>
    {children}
  </Link>
);

but that will throw this error in the browser:

Your <Link>'s as value is incompatible with the href value. This is invalid.

It's a problem reported in https://github.com/zeit/next.js/issues/7488.

After all this, I don't think there's a solution until something like basePath is supported, which I'd be happy to help with.

@borekb I am also ready to help as I mentioned couple of times before. All workarounds I saw until now solve only part of the problem. Right now we are using a fork of next.js in production which implements basePath.

We're going to introduce a new API soon that will make this proposal obsolete.

@tim Is it still the case or was the new proposal for API closed? https://github.com/zeit/next.js/issues/7329

Btw. tomorrow it will exactly one year I opened this issue 🎉

One relatively wild idea is to have pages in something like src/pages and then symlink them to the proper location. For example:

• To deploy to myapp.example.com, I'd symlink src/pages to pages
• To deploy to example.com/myapp, I'd symlink src/pages to pages/myapp

In combination with custom <Link> component and assetPrefix, it _could_ work but I'm not brave enough to try it 😄.

Any update with that?

Any progress on basePath support? :)

@nicholasbraun

Now on every Link click or Router push event the page reloads frowning_face

I had this issue but fixed using the 'as' parameter on the link, so the link points to the internal file, but the 'as' is relative to path
eg:
<Link href={"/${item.link}"} as={"./${item.link}"}>

You saved my day! :)))

i am doing the same with Router.push(`/route`, `${process.env.BASE_PATH}route`);

@nicholasbraun

Now on every Link click or Router push event the page reloads ☹️

I had this issue but fixed using the 'as' parameter on the link, so the link points to the internal file, but the 'as' is relative to path
eg:
<Link href={"/${item.link}"} as={"./${item.link}"}>

This solution does not work with next 9 file based routing. /route/[id], ${process.env.BASE_PATH}/route${id} throws this error

This comment explains the problem very well.

Although i've seen a few people discuss how the solutions here break pre-fetching. For us theres another more important issue.

With next9, using an assetPrefix in your href makes next _always_ perform a server route. I have created a reproduction repo in this issue which demos it happening.

This essentially breaks our Apollo Client cache, as it is re-created on every route.

I think the implementation is comparing the underlying page href without an assetPrefix, to the next routes href (which includes an assetPrefix) - resulting in a deep route.

e.g If you are on href /prefix/page (underlying page is just /page) and your next href route is /prefix/page/[id] (because without the prefix it will 404) this is a compeltely different route and a shallow route isnt possible.

Looking into workarounds at the minute with express routes

When use component with the href props that is basePath, the prefetch is not working.
PLZ support basePath and prefetch, it will be awesome

I could really use this. I'm running multiple apps from a single server source and have each separated into its own web/appX/{next project files}. It'd be great to have more control over the basePath. I've figured out a workaround for now, but its not very pretty.

static export also need basePath 😊

seems work success 👏

{
  experimental:{
    basePath: '/some/dir',
  }
}

This is pretty bad limitation for us unfortunately :(

We have all apps behind a reverse proxy so paths need to be prefixed (in the example below this is prefix of /auction-results)

We use assetPrefix prefix already - and this allows apps to run ok for server side requests.
Eg: mydomain.com/auction-results/ works fine by using some express routing like such:

router.get(`/${appPrefix}/`, (req, res) => {
  nextApp.render(req, res, '/national', req.params);
});

But when we try and do client side nav via next/link, eg:

Where /auction-results is the application prefix, and /national is the page in ~pages/national

<Link href="/national" as="/auction-results/">
  <a>Goto National Page</a>
</Link>

This does nothing (ghost click)

Having full page refresh links is less than ideal.

If there is any way i can help with this I would love to

Any update on this... last year around this time i ran into this issue. Now a year later, i'm working on a new app and have to do the same workarounds i did last year... kinda alarming for a 'production-ready' react fw. Basepaths should be a vanilla feature.

Any update on this... last year around this time i ran into this issue. Now a year later, i'm working on a new app and have to do the same workarounds i did last year... kinda alarming for a 'production-ready' react fw. Basepaths should be a vanilla feature.

I'm not sure what you're expecting by posting this.

Next.js is being worked on full-time by my team (5 people), and we're working on many features at the same time. In the past year we've worked on these:

• https://nextjs.org/blog/next-9
• https://nextjs.org/blog/next-9-0-7
• https://nextjs.org/blog/next-9-1
• https://nextjs.org/blog/next-9-1-7
• https://nextjs.org/blog/next-9-2
• https://nextjs.org/blog/next-9-3

Effectively making Next.js applications (new and existing) significantly smaller, faster and more scalable.

If you want to voice your "upvote" for a feature you can. use the 👍 feature on the initial thread.

I definitely agree basePath should be a built-in feature. It's on the roadmap already and I even wrote an initial PR, which you could have seen by reading back on the thread.

Here's the PR: https://github.com/zeit/next.js/pull/9872

Feel free to reach out to [email protected] if you want to financially contribute to making this feature happen.

What is the Status on this? we are really depending on this :/

@Sletheren basePath support is experimental right now, use at your owm risks.

cf. https://github.com/zeit/next.js/pull/9872

@Sletheren basePath support is experimental right now, use at your own risks.

cf. #9872

@martpie I already saw it, but for. my case basePath is not just one, it can be multiple basePath, since we serve our app through different "URLs" and setting up basePath during build time is not an option (even though it has to support an array of paths rather than a single string)

@timneutkens Thanks for the update. Would you be so kind to give another update. This is for us a key feature and we need to know...

1. Will this be an enterprise-only (your reference to contact enterprise sales caused some irritation)?

2. It seems to be on the roadmap, according to the PR it won't be removed again; can you give some indication if it's safe to build around this feature now without getting any surprises in the next months like a crippled open source version and another one with full support after we negotiated weeks with some random sales guys about arbitrary prices?

I understand that you guys work on many features and everyone has his/her priorities but even smaller setups need to proxy Next, run multiple instances and give it a dedicated basePath per service. Before we now start to build multiple services on Next we need to know how probable and soon this feature is available as full open source. Otherwise it would be just too risky invest further time into Next.

Thanks for your understanding and looking fwd to your feedback.

FWIW, I got it now working and for others driving by:

Put this in your next.config.js:

module.exports = {
  experimental: {
    basePath: '/custom',
  },
}

Then, I needed to restart the server and to setup my web server middleware properly:

I catch all requests via a custom path, eg. app.use('/custom', (req, res...) => { ... and then (which was important) I need to proxy to the URL of the system where Next is running (so the internal address of your container orchestration and again with the respective path if you use http-proxy => eg. ... target: 'http://next:3000/custom), so not just the host without the custom path. If you use http-proxy-middleware you do not need this.

It feels quite ok, I hope that this feature won't need any EE license. If your team needs any help to get this feature mature, pls let us know, maybe we can help!

Edit: Just tried this also in with Next's production mode and it seems to work as well.

@timneutkens Thanks for the update. Would you be so kind to give another update. This is for us a key feature and we need to know...

1. Will this be an enterprise-only (your reference to contact enterprise sales caused some irritation)?
2. It seems to be on the roadmap, according to the PR it won't be removed again; can you give some indication if it's safe to build around this feature now without getting any surprises in the next months like a crippled open source version and another one with full support after we negotiated weeks with some random sales guys about arbitrary prices?

I understand that you guys work on many features and everyone has his/her priorities but even smaller setups need to proxy Next, run multiple instances and give it a dedicated basePath per service. Before we now start to build multiple services on Next we need to know how probable and soon this feature is available as full open source. Otherwise it would be just too risky invest further time into Next.

Thanks for your understanding and looking fwd to your feedback.

@pe-s I think you're misunderstanding my post.

There is no "enterprise Next.js version" as of now. I was referring to the numerous occasions where external companies reached out to pay for consulting to build out features like this one in a shorter timespan. E.g. zones support was built in collaboration with Trulia.

This feature is being worked on still and is on the roadmap. All features being worked on are open-source, like I said there's no enterprise version of Next.js. We have multiple priorities of high-impact work on the roadmap though hence why I referred to contacting [email protected] if you need this feature as soon as possible / to discuss enterprise support for Next.js.

@timneutkens tx for your quick response and great! Then, we can go all in :)
Keep up the great work!

Basepath support is out on next@canary right now, it's no longer experimental. It will be on the stable channel soon.

I'm pretty late to this but did you consider using actual HTML <base> instead of manually handling this?

Basepath support is out on next@canary right now, it's no longer experimental. It will be on the stable channel soon.

@timneutkens, thank you for this addition. Do you know when the non-experimental basePath support will be officially released?

Also, when I set the basePath the assets (located in the public folder) gets served to the appropriate url as expected. But, when I reference them in my code then I have to add the base path to the src manually, because otherwise they will still be referenced from the normal path. Is this the expected use of basePath? I have also tried using assetPrefix, but it didn't have any effect to my code that I could tell.

Example:

1. using next v9.4.5-canary.24
2. basePath set to /alerts in next.config.js:

const basePath = '/alerts';
module.exports = {
  basePath: basePath,
  env: {
    BASE_PATH: basePath,
  },
};

1. asset located in public/images/example.png
2. example use of asset in react component:

const ExampleImage = () => (
  <img src={`${process.env.BASE_PATH}/images/example.png`} />
);

In my tests, it's not updating assets urls.

I installed the latest canary:
npm install [email protected]

next.config.js

const isProd = process.env.NODE_ENV === 'production';

module.exports = {
  basePath: isProd ? '/example' : ''
}

All pages and links load correctly:
http://localhost:3000/example/posts/pre-rendering
http://localhost:3000/example/posts/ssg-ssr
http://localhost:3000/example/posts/pre-rendering

But images, favicons etc are not mapped:
http://localhost:3000/favicon.ico 404
http://localhost:3000/images/profile.jpg 404

Did anyone test this? I also tried using assetPrefix, but that didn't work either.

In addition i'm confused, why not use the built in browser functionality for this?
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/base

Thank you for looking into this on your end as well @kmturley . Glad to know it's not just me.
@timneutkens , should we reopen this issue / create a new issue for this bug?

You have to prefix images manually. You can get the basePath using

const {basePath} = useRouter()

https://nextjs.org/docs/api-reference/next.config.js/cdn-support-with-asset-prefix

Next.js will automatically use your prefix in the scripts it loads, but this has no effect whatsoever on the public folder;

Now, I come to realize there are multiple ways to link to files in /public. e.g. <img/> <link/> ...
Is this why we have to manually specify the basePath to the each?

If there was a component like below available, I think it would save time and reduce confusions for a lot of people?

<WithinBasePath>
  {/* automatically fixes the path with basePath */}
  <img src="/logo.png" />
</WithinBasePath>

I really don't think this is appropriate, but this is what I meant.

// src/components/WithinBasePath/index.tsx

import React from "react"
import path from "path"
import { useRouter } from "next/router"
interface Props {}

const WithinBasePath: React.FC<Props> = (props) => {
  const { basePath } = useRouter()
  const children = [props.children].flatMap((c) => c) as React.ReactElement[]
  return (
    <>
      {children.map((child, key) => {
        let newChild = null

        switch (child.type) {
          case "img":
            newChild = React.createElement(child.type, {
              ...child.props,
              src: path.join(basePath, child.props.src),
              key,
            })
            break
          case "link":
            newChild = React.createElement(child.type, {
              ...child.props,
              href: path.join(basePath, child.props.href),
              key,
            })
            break
          default:
            newChild = React.createElement(child.type, {
              ...child.props,
              key,
            })
        }
        return newChild
      })}
    </>
  )
}
export default WithinBasePath

// pages/test.tsx

import React from "react"
import WithinBasePath from "@src/components/WithinBasePath"
interface Props {}

const test: React.FC<Props> = (props) => {
  return (
    <WithinBasePath>
      <img src="/123.jpg" />
      <link href="/abc.jpg" />
      <div>other element</div>
    </WithinBasePath>
  )
}
export default test

For those trying use const {basePath} = useRouter() which is a Hook, to work with Classes and Components and getting this error:

Invalid Hook Call Warning

https://reactjs.org/warnings/invalid-hook-call-warning.html

You can get it working using:

import { withRouter, Router } from 'next/router'

class Example extends Component<{router: Router}, {router: Router}> {
  constructor(props) {
    super(props)
    this.state = {
      router: props.router
    }
  }
  render() {
    return (
      <Layout home>
        <Head><title>Example title</title></Head>
        <img src={`${this.state.router.basePath}/images/creators.jpg`} />
      </Layout>
    )
  }
}
export default withRouter(Example)

If you want to use basePath with markdown, it looks like you need to do a find and replace in the string:

const content = this.state.doc.content.replace('/docs', `${this.state.router.basePath}/docs`);
return (
<Layout>
  <Container docs={this.state.allDocs}>
    <h1>{this.state.doc.title}</h1>
    <div
      className={markdownStyles['markdown']}
      dangerouslySetInnerHTML={{ __html: content }}
    />
  </Container>
</Layout>
)

You have to prefix images manually. You can get the basePath using

const {basePath} = useRouter()

This solution doesn't take images imported in a css or scss file into account though. Do you have a solution for how to set the base path when importing an asset from within a css or scss file?
With this solution we will have to ensure that all images are imported either through an img tag, inline styling or in the style tag. It's not ideal, because it will split your styles to be implemented in multiple places.

@peetjvv Here's a suboptimal solution for using assets with prefixed basePaths in CSS. Create, import and add a <CSSVariables> component in _app.tsx, which injects a global inlined <style> element containing CSS variables, which you can then use all throughout your stylesheets.

E.g. at the opening of <body> build and inject variables:

<style>
:root {
      --asset-url: url("${basePath}/img/asset.png");
}
</style>

To get that basePath I use the @kmturley's approach using withRouter.
Here's how that component could look like:

import { withRouter, Router } from "next/router";
import { Component } from "react";

export interface IProps {
  router: Router;
}

class CSSVariables extends Component<IProps> {
  render() {
    const basePath = this.props.router.basePath;
    const prefixedPath = (path) => `${basePath}${path}`;
    const cssString = (value) => `\"${value}\"`;
    const cssURL = (value) => `url(${value})`;
    const cssVariable = (key, value) => `--${key}: ${value};`;
    const cssVariables = (variables) => Object.entries(variables)
      .map((entry) => cssVariable(entry[0], entry[1]))
      .join("\n");
    const cssRootVariables = (variables) => `:root {
      ${cssVariables(variables)}
    }`;

    const variables = {
      "asset-url": cssURL(
        cssString(prefixedPath("/img/asset.png"))
      ),
    };

    return (
      <style
        dangerouslySetInnerHTML={{
          __html: cssRootVariables(variables),
        }}
      />
    );
  }
}

export default withRouter(CSSVariables);