Feature request: Basepath support

[tomaswitek]

Feature request

Is your feature request related to a problem? Please describe.

Multi zones is a great feature which allows to run multiple next.js apps on the same domain, but it doesn't allow to define a basepath which will be accepted by all parts of next.js. Since we are not able to namespace apps right now it is not possible to have the same names for pages in various apps.

Describe the solution you'd like

I want to be able to configure a basepath in the next.config.js file. Thanks to this configuration all parts of next.js (Router, Link, Static assets etc.) will be aware of the basepath and will automatically generate and match to the correct paths.

Describe alternatives you've considered

One alternative is to nest all desired pages into a folder which matches the basepath. This solves just one small issue with routing and is quite ugly because most of the my basepaths are not one level paths.
The second alterantive is to configure a proxy in a way where the basepath is automatically removed before the request arrives into a next.js app and also implement a custom Link component which automatically adds basepath to all links. I just don't want to maintain custom fork of next.js. It doesn't make sense in my opinion.

Additional context

The assetPrefix solution allows us to define a different prefix for each app. But as fair as I know it works only with different hosts.

with-zones example

module.exports = {
  assetPrefix: NOW_URL ? `https://${alias}` : 'http://localhost:4000'
}

If I add a basepath to it everything fails

module.exports = {
  assetPrefix: NOW_URL ? `https://${alias}/account` : 'http://localhost:4000/account'
}

In my opinion we should split it into 2 variables:

module.exports = {
  assetPrefix: NOW_URL ? `https://${alias}` : 'http://localhost:4000',
  basepath: '/account'
}

Related issues

• basepath support in nextjs ? #2072
• Multiple Next apps on single domain will collide #257
• Change default root url #2289
• Serving app from /subpath #4969
• Extend assetPrefix for global prefixing #4146

[timneutkens]

cc @jxnblk

[timneutkens]

cc @alexindigo @DullReferenceException

Would love to have your feedback 👍

[tomaswitek]

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:
panter#2 (split)
panter#1 (pass both)

[timneutkens]

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.

[tomaswitek]

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

[timneutkens]

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)

[timneutkens]

cc @alexindigo @DullReferenceException @3rd-Eden

Could you give feedback on the above proposal: #4998 (comment)

[alexindigo]

@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.

[alexindigo]

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.

[alexindigo]

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

[tomaswitek]

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.

[tomaswitek]

@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"

[alexindigo]

@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.

[tomaswitek]

@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.

[tomaswitek]

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.