feat(ssr): add import.meta.pathname as url in ssr

[matthewp]

Description

Based on discord discussion, opening this PR to spark a discussion on import.meta.url. The main thing this does is fix import.meta.url to match Node ESM.

Additional context

This PR does 2 things:

1. Makes import.meta.url be the file URL, matching what Node.js does in native ESM.
2. Creates a separate import.meta.pathname which is the server pathname (what is currently import.meta.url in main). Can bikeshed on the name, but having the server pathname is still useful for doing things like creating URLs for dynamic resources.

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[patak-dev]

Thanks @matthewp. I think we could divide this PR in two. Maybe we could manage to merge the fix for import.meta.url in node, and leave pathname as a feat PR to be discussed in the next team meeting.

A Vite SSR server could run in the edge (ie. cloudflare workers), so I don't know if this should be applied generally. We have a ssr.target config option that can be used to differentiate both cases. @frandiox @brillout could you also help us review this PR?

We would also need a test case that is failing without this fix in one of the ssr playgrounds.

[matthewp]

Thanks @patak-js, happy to split if that's what the team would like.

I haven't tested Cloudflare Workers but in Deno it's the file URL as well. I would expect that to be the case in CW, going to ask their team about that.

[matthewp]

Going to wait for @frandiox @brillout chime in before splitting and adding tests.

[brillout]

Not sure about Cloudflare Workers, but Fran probably knows about this.

Otherwise LGTM.

[frandiox]

We are not using import.meta.url at runtime in Vitedge so I'm not sure how this change behaves in CFW to be honest 🤔
Afaik CFW doesn't have a filesystem. Also, they are working on ES Modules support (currently in beta) so this might even behave differently depending on the way the worker is deployed.

[matthewp]

I deployed a test project in Cloudflare and import.meta.url is undefined. If you use their webpack template then it's the local filesystem URL as expected (because webpack is building to commonjs).

[matthewp]

New PR with just the import.meta.url part: #5268

[matthewp]

@patak-js going to leave this PR open for now, will open a separate one for the pathname feature after #5268 is merged in. I hope this issue is sufficient to discuss the pathname idea.

[patak-dev]

Thanks @matthewp, it would be useful if you could give a concrete example of what import.meta.pathname would enable to help while discussing this new feature. Also, maybe it should be added even out of ssr so it could be used in a generic way?

[matthewp]

@patak-js In Astro we have an API: Astro.resolve('./penguin.png') that would use this under the hood. It allows you to create URLs that are relative to the current module. This needs to be dynamic rather than using ?url so you can do stuff like this (this is a React component):

const thisURL = new URL('http://example.com' + import.meta.pathname)

export default function({ animal }) {
  return <img src={new URL(`../images/${animal}.png`, thisURL)} />
}

This would create an image that output something like /src/images/penguin.png.

---

Having this outside of SSR-only makes sense to me. I'd need some help on the best way to implement that.

[matthewp]

I've been able to workaround this without needing a pathname, due to the fact that Vite is able to resolve full pathnames, so actually having import.meta.url as the file URL is enough.

I'm a little torn on this, as having the front-facing pathname is better in some ways, but adding a non-standard import.meta property means the code is less portable. Closing for now, but happy to continue to discuss.