Convenience injection of rewrites & exportPathMap

[adam-rocska]

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

When using next-intl with:

• output: "export"
• basePath (this might be a red herring)
• Localized Pathnames

Both the built routing, and the dev served routing don't recognize the localized paths.

Describe the solution you'd like

NextJS supports exportPathMap and rewrites in its config.
We could provide such utility functions which could automagically populate the routes according to rational dev expectations.

I'd sugest a wrapper / currying / composition instead of a simple utility function, since library users may already have exportPathMaps or rewrites in place.

If this sounds like a good idea, let me know in the comments and I'll open a PR.
I've got a rough implementation of this solution.

Describe alternatives you've considered

This combination of settings to the best of my knowledge can't be tackled in any other way 🫤

[amannn]

Hey @adam-rocska, thanks for the feature request!

Yep, localized pathnames are known to not work with Next.js' static export since they rely on middleware.

I've honestly not heard of exportPathMap before. It's an interesting feature though that could be really useful for this use case. However, the Next.js docs mention that this feature is deprecated, so I guess it will be removed at some point. Due to this, I think it doesn't make much sense for next-intl to support this in a built-in way.

That said, I guess this could be solved in userland while the feature is available, right? You mentioned that you already have a rough implementation working, mind sharing it in case it could be helpful for others? I'm wondering if in case Next.js removes this feature, this could be implemented via a postbuild script that moves files around appropriately to respect localized pathnames.

[adam-rocska]

@amannn Thanks for the quick reply!

Moving files around post-build makes me a bit edgy 😅 But sure, if this feature no longer will be around at some point, it might smell like it's the only option there.

As of the workaround (deprecated) functions, sure, I'll generalize them later today & have it posted here on the thread.

I wonder what the nextjs team might have in mind for this stuff.

[amannn]

Sounds great thanks! I'll move this to a discussion for now, as I think built-in support in next-intl is off the radar for now.

[adam-rocska]

Thanks!

[adam-rocska]

Well, I wasn't attentive enough and after coding the whole show today morning, it turns out this exportPathMap gig only works with the Pages router, not the App router. Bummer...

[adam-rocska]

Yea, definitely this story is a dead end. Sorry for the excitement.

[amannn]

No worries at all! However, I think this could really be accomplished with a post-build script in userland.

I've just tried building the App Router example with output: 'export' and this is the output:

The app uses localized pathnames and the /pathnames navigation item points to the localized /de/pfadnamen in the German version:

Currently, the page shows a 404 when visited, since Next.js builds a ./de/pathnames.html page.

However, you can fix this as follows:

mv out/de/pathnames.html out/de/pfadnamen.html
mv out/de/pathnames.txt out/de/pfadnamen.txt

If you do this in an automated way based on the pathnames object, this might work just fine.

Maybe that's an option for you?

[adam-rocska]

Well, yes, it could fly. But I'm not sure if this circle of responsibility would best fit in the dependents' side.

I mean, if I produce let's say 10-15 github pages, I would replicate the same black magic in multiple places.

How about delivering CLI utilities with the NPM package? I started to make it a habit of mine over the past two years and it paid off well. In a few it'll also be visible in my open-source stuff.
Basically the idea is to provide a handful of CLI tools (or one with multiple commands) that do plumbing work for the dependents, or give utilities related to the package.

What do you think?

I'm more than happy to show an example pull request or something how it could look like. If it would of-course fit the scope of the package.

[amannn]

Theoretically, if next-intl would support this out-of-the-box, I guess we wouldn't need a CLI command, but we could register a post-build hook since next-intl is set up via a webpack plugin. Based on the current implementation, I think the trickiest part would be to share the pathnames config that is currently typically defined in a file like src/routing.ts. Would we have to import src/routing.ts into next.config.mjs? 🤔 Not sure yet what implications this would have. Two more aspects I can think off the top of my head are dynamic segments and custom prefixes.

It'd certainly be cool to support the output: 'export' better for people who prefer not to run a Node.js server in production. If you're interested in this, you could provide a userland implementation that is published to npm for the time being. In case this proves to work well and there's sufficient demand, we could still evaluating moving this to the core at some point. I'm currently just a bit reluctant since I have some other priorities currently and maintaining code over time takes quite some effort. Hope that's understandable!

We did have the case already a few times where an implementation started out in userland and was migrated into the main package later (e.g. custom prefixes, alternate links). An example of a recent userland plugin is https://github.com/stevensacks/storybook-next-intl; we do also link to this from the docs!