Postgres.js page brakes the layout of the site

[DanieleS]

Describe the bug
Hi, I noticed that opening the the Postgres.js page of the doc brakes the layout of the documentation site. The content of the page goes under the sidebar, and the issue is preserved even on page change, until refresh (on a different page)

To Reproduce
Steps to reproduce the behavior:

• navigate to https://safeql.dev/compatibility/postgres.js

Expected behavior
The page should looks like all the other

Screenshots

Desktop (please complete the following information):

• OS: Windows, but it applies to MacOS as well
• Browser: Chrome, Firefox

Additional context
I tried to investigate a bit and it looks like a combination of issues.

The first one is that the page ends with .js. There is an explicit exception on some file extensions to avoid to treat them as html. Because of this, the generated link in the side menu doesn't get the .html extension as the others.

But even if this holds true, I wasn't able to reproduce it in local. After a bit more investigation, I tried it to deploy it on vercel, and it looks like that the file resolution of vercel and the local server are different. With vitepress serve, while client side navigation is broken, it serves the correct file anyway, with correct Content-Type, event if it has a .js extension. On vercel, instead, it returns the 404 error page, then the bundle is loaded, and, as we are in a known url, the correct js file for the page is loaded. It then renders the content but, as the layout is wrong, it doesn't take into account for the sidebar and the page looks bugged.

Possible solutions
In the beginning I thought it was a vitepress issue, but I would say that their check is not wrong after all.

We can rename the page to something like postgresjs (getting rid of the dot) or adding a .html manually at the end of the links (I found a couple of them, in .vitepress/config.ts and api/index.md)

[karlhorky]

Hm... it does seem like a VitePress bug (probably should be reported over there too). Or maybe even 2 VitePress bugs.

As you mentioned above, all of the other links in the side navigation go to URLs with .html at the end.

And navigating to https://safeql.dev/compatibility/postgres.js.html (with .html at the end) shows a non-broken page:

In contrast, navigating to https://safeql.dev/compatibility/postgres.js (without the .html) shows a broken page (with missing content):

The VitePress config does not include the .html in the link property:

safeql/docs/.vitepress/config.ts

Lines 34 to 42 in 35b5ea2

	text: "Compatibility",
	items: [
	{ text: "Prisma", link: "/compatibility/prisma" },
	{ text: "Postgres.js", link: "/compatibility/postgres.js" },
	{ text: "@vercel/postgres", link: "/compatibility/vercel" },
	{ text: "slonik", link: "/compatibility/slonik" },
	{ text: "node-postgres (pg)", link: "/compatibility/node-postgres" },
	{ text: "Sequelize", link: "/compatibility/sequelize" },
	],

So this seems like 1 or 2 VitePress bugs:

1. Using .js in a link property does not link to the .js.html URL
2. The page shows shows incomplete content (and also shows a 404 briefly at the start)

@DanieleS could you open 1 or 2 bug(s) for these over in VitePress and link them back here?

[karlhorky]

@Newbie012 I think this is still broken, if you visit this page directly (maybe needs a redirect to the https://safeql.dev/compatibility/postgres.js.html page:

• https://safeql.dev/compatibility/postgres.js

[Newbie012]

That's correct, but is it really an issue if we always link to .html? I don't mind reopening this issue; it just feels negligible now that we consistently point to .html.

[karlhorky]

I guess so, but I would worry about external sources - ending up somehow in a search engine index (not currently in Google, it seems) or linked to from a different third party.