🗺️ Upgrade to react-router: 7

[agoose77]

We are currently using Remix 1.x, and the latest version is effectively Remix 3.x (react-router 7). This PR is a spike that reworks a previous upgrade attempt to use react-router. It needs a close eye, and only focuses on the book theme.

My intention here is to leave this open when I get some time to move it forward, and to explore the interesting new features like basepath handling, prerendering, etc.

Ignore the blame and commit count -- the commits need to be squashed into something more manageable.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 34bde3b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[choldgraf]

In order to help us prioritize this work alongside other things that might require a lot of team discussion and review, I think it'd help if (as part of your spike) you included a list of the most important

• problems users have that will be solved by this upgrade
• new things users will be able to do that this update is a blocker for
• problems that maintainers have that will be solved by this upgrade
• strategic risks that we have if we do not upgrade

[agoose77]

In order to help us prioritize this work alongside other things that might require a lot of team discussion and review, I think it'd help if (as part of your spike) you included a list of the most important

* problems users have that will be solved by this upgrade

* new things users will be able to do that this update is a blocker for

* problems that _maintainers_ have that will be solved by this upgrade

* strategic risks that we have if we do not upgrade

Agreed. Right now I do not know the answer to most of these questions, as I do not know what react-router addresses in terms of the known problems with Remix 2. As this PR moves forward and figures those parts out, I'll update the PR description!

[agoose77]

The first thing that I think we might want to do is to have the theme proxy content-server requests. In other words, rather than the rendered web-page linking to https://my-cdn.com/static/foo.png, it links to ./static/foo.png, which in turn resolves the CDN. The benefit of this is that people running theme applications do not need their CDNs to be externally visible (or proxied alongside the application to make it work). This is helpful for running myst start on a JupyterHub.

Practically, this means instead of rewriting content links in the theme to ${CONTENT_CDN}/${path} we rewrite to ./static/${path}.

[netlify]

❌ Deploy Preview for myst-theme failed. Why did it fail? →

Name	Link
🔨 Latest commit	34bde3b
🔍 Latest deploy log	https://app.netlify.com/projects/myst-theme/deploys/6914c32d48cafe0008413435

[stevejpurves]

Practically, this means instead of rewriting content links in the theme to ${CONTENT_CDN}/${path} we rewrite to ./static/${path}.

@agoose77 will that have a negative/any impact on the static build?

[agoose77]

Practically, this means instead of rewriting content links in the theme to ${CONTENT_CDN}/${path} we rewrite to ./static/${path}.

@agoose77 will that have a negative/any impact on the static build?

I don't think so. I think the idea I had is that a deployed theme should not expose CDN information in the rendered page, i.e.

myst-theme[node.js] <-> CDN

is fine, but

myst-theme[browser] <-> CDN

is not.

IIRC the theme already does this link rewriting, so it should not be too hard to rewrite e.g. image URLs on "myst start" instances to point to "/base-url/static/XXXinstead of<CONTENT_CDN>/XXX`