-
-
Notifications
You must be signed in to change notification settings - Fork 6.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: ?import with trailing = added by some servers #3805
Conversation
More context: Seems like most URL parsers expect the |
?import
querystring breaking in other dev servers (Vercel support)?import
querystring breaking in other servers and URL parsers (including Vercel CLI)
…uery strings (i.e. vercel)
Caught one |
Just switched from |
Going to update regex momentarily. Wanted to share some thoughts for vite's query params in the longer term I do not plan on making these changes, and knowing the ecosystem expectations around these flags, they would be breaking and as such best suited for a major release IMO, there is value in changing these to better match the expected Perhaps a vite-specific key with many values would be better? I.e. |
Should be good for another look @patak-js |
The issue with this is that this form import Worker from './shader.js?worker&inline' is a lot terser and has a better signal to noise ratio than import Worker from './shader.js?viteflags=worker,inline' But the standard will be quite verbose here also import json from "./foo.json" assert { type: "json" }; So maybe we could use something like |
?import
querystring breaking in other servers and URL parsers (including Vercel CLI)
Description
Vercel's cli tries to resolve all paths before passing them to the frontend dev server. During these checks, it parses query strings. During this parse, it modifies
?import
to be?import=
, which the vite dev server fails to resolve :(To prevent this from breaking in Vercel and other dev servers, I've modified the
?import
query param to include a value:?import=vitedev
Most servers and URL parsers assume that querystrings are key:value pairs, bound with
=
, and I think it is reasonable to encode that assumption. At the very least, a trailing=
should be supported (as most parsers assume this is the case).That said, I'm more than happy to investigate another solution - let me know if you would prefer an alternative :)
Additional context
Issue:
#3781
Attempt to fix on Vercel CLI side, includes good discussion on why this should be fixed here:
vercel/vercel#6359
Example of
=
being appended by standard browser URL interfaceWhat is the purpose of this pull request?
Before submitting the PR, please make sure you do the following
fixes #123
).