Closed xcao38 closed 2 years ago
We just released a change affecting kit.paths.base
(changelog. CC @Karlinator). Do you get the same error with version 1.0.0-next.169
?
This is only an issue in preview, right? I think this is just #2409 showing up?
Does it run correctly with npm run dev
and when using the node adapter (node build
after npm run build
)? If it does, then this should be fixed by #2409
This is only an issue in preview, right? I think this is just #2409 showing up?
Does it run correctly with
npm run dev
and when using the node adapter (node build
afternpm run build
)? If it does, then this should be fixed by #2409
@benmccann @Karlinator thanks. Do you mind show me the command to upgrade to the latest version?
@xcao38 #2409 isn't merged yet, so you won't get it even with upgrading. It'll probably be live soon-ish though. If your package.json
has explicit version names (say, 1.0.0-next.169
) you can just change that and run npm i
. Also npm i -D @sveltejs/kit@1.0.0-next.170
will do the trick. If you have the version just specified as next
then a simple npm update
(or npm update @sveltejs/kit
I think) will update.
This is only an issue in preview, right?
Not according to the issue report which says its an issue in dev and preview:
Then run
npm run dev
ornpm run build
andnpm run preview
.
Ugh, my eyes betray me.
There might be a similar issue in the dev server, I haven't looked. I'm not as familiar with Vite and all that, but that would be my guess.
There is this line: https://github.com/sveltejs/kit/blob/7dec53ecc66793841cf7702cb8d7453bb5cb5bad/packages/kit/src/core/dev/index.js#L296
Maybe assets are rejected at that point?
@xcao38 do you have the full path of the files the browser is requesting? Is it requesting all assets in the correct locations (/testdir/_app/whatever
) in both dev and preview (and are the paths the same in dev and preview)?
If those paths are all correct then I think we have one bug in preview (already known) and a separate but similar bug in dev (manifests the same, but caused differently since dev and preview servers are quite different internally, what with Vite etc).
@xcao38 do you have the full path of the files the browser is requesting? Is it requesting all assets in the correct locations (
/testdir/_app/whatever
) in both dev and preview (and are the paths the same in dev and preview)?If those paths are all correct then I think we have one bug in preview (already known) and a separate but similar bug in dev (manifests the same, but caused differently since dev and preview servers are quite different internally, what with Vite etc).
I could show you my file structure. Not sure where to find the files... Let me know if you need anything :)
I meant the network log from the browser 😅 I want to see if the links and source urls embedded into the page are correct. In your devtools 'Network' tab you can click on the requests and just see if the Request URLs all have '/testdir/' in them. They should look like localhost:3000/testdir/_app/pages/whatever
. If tehy look like localhost:3000/_app/pages/whatever
(without 'testdir' in tehm) then we have a different problem.
I meant the network log from the browser 😅 I want to see if the links and source urls embedded into the page are correct. In your devtools 'Network' tab you can click on the requests and just see if the Request URLs all have '/testdir/' in them. They should look like
localhost:3000/testdir/_app/pages/whatever
. If tehy look likelocalhost:3000/_app/pages/whatever
(without 'testdir' in tehm) then we have a different problem.
Here you go:
Hi @Karlinator thanks for the quick turnaround! Just curious, is there a timeline on releasing the new updates on paths.base
?
The pretender change is in 170 and the preview mode change is in 171: https://github.com/sveltejs/kit/blob/master/packages/kit/CHANGELOG.md
I don't think 170 or 171 actually fixes the dev mode issue here. 170 fixed an issue in pre-rendering, 171 fixed an issue in the preview server. I haven't had time to reproduce and go digging, but it looks like there's a separate issue in the dev server.
@benmccann @Karlinator Thanks both for your time! FWIW, I upgraded my sveltekit to 171 with following:
npm add -D @sveltejs/kit@1.0.0-next.171
.
Then I run npm run build
and npm run preview
, the problem with assets not found is gone. What I can see on my screen and console is as following:
(base) Xiaofengs-MacBook-Pro:my-app xiaofengcao$ npm run preview
> my-app@0.0.1 preview /Users/xiaofengcao/projects/svelte/my-app
> svelte-kit preview
SvelteKit v1.0.0-next.171
local: http://localhost:3000
network: not exposed
Use --host to expose server to other devices on this network
{
"name": "my-app",
"version": "0.0.1",
"scripts": {
"dev": "svelte-kit dev",
"build": "svelte-kit build",
"preview": "svelte-kit preview"
},
"devDependencies": {
"@sveltejs/adapter-node": "^1.0.0-next.49",
"@sveltejs/kit": "^1.0.0-next.171",
"svelte": "^3.34.0"
},
"type": "module",
"dependencies": {
"@fontsource/fira-mono": "^4.5.0",
"@lukeed/uuid": "^2.0.0",
"cookie": "^0.4.1"
}
}
I believe you need the trailing slash, so localhost:3000/testdir/
.
I believe you need the trailing slash, so
localhost:3000/testdir/
.
Thank you! very helpful. Yeah it did the trick:)
This is still an issue in 177. Once you revert to Vite for previewing, will this fix the issue when there is no trailing /
?
I don't think we'll use Vite for preview mode actually. What they do for their preview
mode is too different (e.g. it doesn't do SSR at all)
Closing this as a duplicate of https://github.com/sveltejs/kit/issues/2958
Describe the bug
After set config as following in svelte.config.js:
npm run dev
: Inhttp://localhost:3000/testdir
, I got the following:npm run build
&npm run preview
:Reproduction
Step 1: start a sveltekit app: https://kit.svelte.dev/
Step 2: change
svelte.config.js
to following:Step 3: install @sveltejs/adapter-node
Then run
npm run dev
ornpm run build
andnpm run preview
.Logs
No response
System Info
Severity
blocking all usage of SvelteKit
Additional Information
We are trying to release a sveltekit app under a sub url. This is seriously blocking our deployment.