Use /x or /mod instead of /package

[martonlederer]

Right now we are using the /package/:pkgname route for modules. To align more with the Deno philosophy, we could switch to /x/:modname or /mod/:modname

[SteelAlloy]

I completely agree After that it would also be a good idea to replace all occurrences of the word package by module in the internal code

[martonlederer]

We could also add a simple redirect for /package/:pkgname. Luckily we don't have it in the actual registry URLs

[t8]

I like this idea. I would prefer not to have /x (just to avoid confusion between x.nest.land and nest.land/x) unless we can get something working like how deno.land/x does it...

Though, I think @maximousblk has looked into this before, and it may be more effort than I think.

Regardless, @martonlederer's idea of a redirect from the current references would be absolutely critical.

[martonlederer]

It can be done with cloudflare workers. We should talk about this too in our meeting

[maximousblk]

it can also be done with vercel functions. I couldn't implement it in a simple way earlier because the URLs for the raw and web versions were way different. It won't take much effort if the routes work the same way on the web and in deno

what we have now:

• URL for web: https://nest.land/package/eggs/files/mod.ts
• URL for deno: https://x.nest.land/[email protected]/mod.ts note: the website is client side rendered so increases complexity when requesting a specific version. also, the current website supports linking to a specific version using a ...?v=0.2.3 query, but that doesn't work for the /files route. (bug?)

what we need:

• URL for web: https://web.nest.land/x/[email protected]/mod.ts
• URL for raw: https://cdn.nest.land/x/[email protected]/mod.ts

then we can create a serverless function to forward the requests to the right place and deploy that to https://nest.land/...

you can boil all of that down to "the site is inconsistent"

[VienDinhCom]

Use the term "module" instead of "library" or "package".

For clarity and consistency avoid the terms "library" and "package". Instead use "module" to refer to a single JS or TS file and also to refer to a directory of TS/JS code.

https://deno.land/[email protected]/contributing/style_guide#use-the-term-quotmodulequot-instead-of-quotlibraryquot-or-quotpackagequot

I think we should use https://deno.land/std for Standard Library and https://deno.land/x for Third Party Modules just like the https://deno.land/.

[t8]

Hi @Maxvien! Thanks for the input.

This was our original plan for the system, however, we encountered some technical issues with that. Because our API is completely separate from the site, we had to put x on its own subdomain.

I wouldn't be against investigating a solution to allow for the /x and /std routes on Nest.land, but I personally do not know of a way around this issue. Note: We'd like to keep our Vercel sponsorship, as our site development/deployment workflow is massively simplified this way.

[jasonappah]

I wouldn't be against investigating a solution to allow for the /x and /std routes on Nest.land, but I personally do not know of a way around this issue. Note: We'd like to keep our Vercel sponsorship, as our site development/deployment workflow is massively simplified this way.

If I'm understanding this correctly, we should be able to get away with setting up routes in the vercel.json file. See here for more info.

Basically at the root of the repo we would create the vercel.json file, and add something like this:

{
  "routes": [
    { "source": "/x/(.*)", "destination": "https://x.nest.land/$1" },
    { "source": "/std/(?<ver>[^/]+)/(.*)", "destination": "https://x.nest.land/std@$ver\$STD_VERSION/$1" }
  ]
}

[maximousblk]

yes we can set the routes in the vercel.json file but that won't let us dynamically serve the website and raw module based on the request.