-
-
Notifications
You must be signed in to change notification settings - Fork 6k
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
feat!: relative base #7644
feat!: relative base #7644
Conversation
Tests are passing, except for Windows. We are probably missing a path normalization. More testing is still needed, I changed some playgrounds to use relative base, and tested by hand in some others (there is a new |
Looks like tests are failing because this line is missing
In addition, I think this PR will fix #5270 and #7279 since |
I don't know how disruptive it could be for the ecosystem, but relative paths seem like a better default to me than Note: Right now, during dev even if the user sets |
Posting my reply in the Discord channel here for a more public discussion: The relative base path doesn't work well for code-splitting. That's why webpack introduced Note that even if we follow the webpack approach, the
|
I think what this PR is doing for I like having a |
Co-authored-by: Bjorn Lu <[email protected]>
@benmccann would you be able to review this PR and check if most use cases discussed in sveltejs/kit#595 (or involve others from the Svelte community that may be interested in helping push this change forward?) @wighawag it would be good if you could check this PR, and see if it would help you with https://github.com/wighawag/sveltejs-adapter-ipfs For context, this PR may be later complemented with an option to define the URL for the assets path dynamically (and public files path, but I think SvelteKit isn't using the public folder), #3522 (comment) (still keeping relative as many of the URLs as possible) |
@Rich-Harris might be the best person to take a look at this one. I see @dominikg and @bluwy have both taken a look at this PR as well though |
Co-authored-by: Bjorn Lu <[email protected]>
Confirmed that this now works for a SvelteKit test case, the only change needed being to change |
We already discussed with the team and approved changing the modern browser targets increasing the baseline to browsers supporting Let's merge the PR so we can start building on top of it. There are changes I think would be good to make but it will be easier to discuss them in separate PRs. It is also better if we can later release a new v3 alpha patch with it so we start getting more testing from the ecosystem. |
Released as part of [email protected] |
I still find this very difficult to actually make happen, and the documentation is not as clear on how to do it and specifically what it does as I think Vite thinks it is. |
fix #2009
fix #5270
Description
Makes built apps portable when using relative base (
base: './'
orbase: ''
).When using a relative base, there shouldn't be any absolute URL. Including paths to public files and paths to assets from HTML files.
Related discussions:
Why we need relative base support, from @Rich-Harris's comment:
Update to modern browser targets
We need support for
import.meta.url
to be able to find the assets URL in some cases (for the preload URLs for example).import.meta
is at 91.22%, and we are currently requiredynamic import support
so we are at 91.47%. Given thatimport.meta.url
will enable us to implement features like this PR, and the numbers will keep getting better, I think we could change our default modern target in Vite v3 and push an extra 0.25% of users to legacy mode. See Discussion with @bluwy and @sapphi-red in Discord hereThe new esbuild resolved target upgrades
'es2019'
to'es2020'
and downgrades safari from13.1
to13
so we keep transpiling nullish coallesing (still at ~89%)@vitejs/plugin-legacy
is updated to checkimport.meta
support (on top of dynamic import support):Asset URLs replacements in JS files
Edit: after a discussion with @bluwy, he proposed we keep using quotes and
JSON.stringify
and interpolate using" + ... + "
.Alternative interpolation strategy that is no longer used in the PR
For assets paths imported from a JS file, or for CSS inlined with asset URLs, we need to use
import.meta.url
to obtain a runtime absolute path because these strings can be re-exported and used in other files, or used directly in the DOM.Instead of plain strings
We could use template literals in these cases
Allowing us to inject runtime interpolation with
new URL(...,import.meta.url)
Note
During the Vite 2.0.0 beta, 00bc446 added relative base support, fixing #1669. Afterward, tests for relative base weren't included in Vite's CI. So the code evolved and we lost support for this feature.
What is the purpose of this pull request?