Linking to specific version of package returns 404

[dkazmer]

Linking the following URL from Bluesky yields 404 error and the weird transformed URL thereafter.
https://npmx.dev/package/obsidium/v/3.1
https://npmx.dev/package/[name]/v/[version]-isr

npmx has a lot of flaws and they've blocked me there because I dared to expose them (even constructively).
I'll probably go back to using regular npmjs.com

[mikouaji]

Looks like a ISR regression, npmx tries to cache very aggressively so its possible with working on it this issue was introduced. Thanks for reporting.

[danielroe]

the issue here is that 3.1 is not a valid version.

you can use https://npmx.dev/package/obsidium/v/^3.1

we should probably improve the error you get when you link to an invalid/incomplete version (or redirect to a valid one)

npmx has a lot of flaws and they've blocked me there because I dared to expose them (even constructively).

no idea what you're talking about but we very much welcome the reporting of bugs 🙂

[dkazmer]

@mikouaji thanks. Yeah, I noticed the aggressive caching. I have to open up dev tools and then refresh the browser to load the new data.

@danielroe

no idea what you're talking about

I'm sure you don't but nonetheless...
The error message could include a note about proper version URLs (with the little cap), or better yet, just cache the same way as npmjs.com

[danielroe]

this isn't related to caching

[danielroe]

you can see npm doesn't work either, because it is an invalid version:

https://www.npmjs.com/package/obsidium/v/3.1

[dkazmer]

Test links for comparison
https://www.npmjs.com/package/obsidium/v/3.1.0
https://npmx.dev/package/obsidium/v/3.1.0

[dkazmer]

@danielroe the first in above test works as expected, while the second doesn't..
Test w/ cap: https://npmx.dev/package/obsidium/v/^3.1
This one kinda works, but omits the README

[alex-key]

Some more details for reproduction:

• Go to https://npmx.dev/package/obsidium
• Click 3.1.0 (latest version)
• See URL is correct (https://npmx.dev/package/obsidium/v/3.1.0)
• Refresh the page
• Url is broken, page is broken

I will try to investigate. It should be some incorrect logic with redirection for the latest version (where "package/{name}" and "package/{name}/v/{latest}" should be the same)

[alex-key]

Daniel @danielroe , I think the problem is some issue with ISR on a Vercel side (@mikouaji mentioned).
I tried to reproduce locally, but cannot do it (I suppose ISR cannot be tested locally).
Also on npmx.dev this issues is reproducible quite randomly. But it's always related to reloading a package page with version in URL (/package/[name]/v/[version]). The package above (https://npmx.dev/package/obsidium/v/3.1.0) - is a very good example, where issue is reproducible 90% of the time.

I suppose ISR is still quite fresh feature and seems like noone have enough expertise on this except you.

[userquin]

Looks like an issue with 404 response, page refresh using Nuxt 0.1.8 (Firefox with 500 in the tittle), and it is a valid version: https://discord.com/channels/1464542801676206113/1464544758020968448/1475092654478983313

Chrome Nuxt v0.1.8 404 response

[alexdln]

Additional details for now:

• Server always sees the wrong path for version pages. But sometimes it returns a blank page, and once on the client, it manages to work correctly and displays the page as expected [scr 1, 2].
• Sometimes it redirects immediately, apparently on the client. That is, the request path is correct, but the response immediately shows that the path is segmented, not injected parameters
• Definitely server routing issue. But when there's a trailingSlash at the end of the path, the problem doesn't reproduce (https://npmxdev-git-fork-alexdln-chore-test-route-overriting-npmx.vercel.app/package/obsidium/v/3.1.0/)
• But if we enable trailingSlash in the vercel settings, then for versions it will always redirect to a page without it (?!)
• It seems to redirect when we request for the version failed for some reason (f.e. rate limit). That is, if our request failed, we get a server error and a redirect. And if it somehow went through, we get a blank page from server, since the [name] package doesn't exist and then we trying to load it client-side

So #1530 is related to this one