Closed peterbud closed 1 year ago
I couldn't reproduce the problem on mac.
System: OS: macOS 10.15.7 CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz Memory: 4.02 GB / 32.00 GB Shell: 5.7.1 - /bin/zsh Binaries: Node: 14.15.0 - ~/.nvm/versions/node/v14.15.0/bin/node Yarn: 1.22.10 - ~/.nvm/versions/node/v14.15.0/bin/yarn npm: 6.14.8 - ~/.nvm/versions/node/v14.15.0/bin/npm Browsers: Chrome: 83.0.4103.106 Edge: 90.0.818.66 Safari: 13.1.3 npmPackages: vite: ^2.4.4 => 2.5.0
I came here looking for a solution to a similar issue.
I'm also on Windows, and am seeing the same results with an even simpler repro:
npm init vite@latest
(Note: the yarn create vite
doesn't work if you have Node 14 installed. 👎)svelte
svelte-ts
yarn
yarn dev
From Chrome DevTools:
From Firefox DevTools:
In both cases the second main.ts
is the esbuild
-compiled file and not the actual source.
It looks like there needs to be a way to specify a "root" folder that gets stripped?
Looks like the problem isn't with esbuild
, either:
$ yarn esbuild D:/projects/qc/tempvite2/vite-project/src/main.ts --sourcemap
import App from "./App.svelte";
export function test(a) {
return a + 1;
}
const app = new App({
target: document.getElementById("app")
});
export default app;
//# sourceMappingURL=data:application/json;base64,ewogICJ2ZXJzaW9uIjogMywKICAic291cmNlcyI6IFsic3JjL21haW4udHMiXSwKICAic291cmNlc0NvbnRlbnQiOiBbImltcG9ydCBBcHAgZnJvbSBcIi4vQXBwLnN2ZWx0ZVwiO1xuXG5leHBvcnQgZnVuY3Rpb24gdGVzdChhOiBudW1iZXIpOiBudW1iZXIge1xuICAgIHJldHVybiBhICsgMTtcbn1cblxuY29uc3QgYXBwID0gbmV3IEFwcCh7XG4gICAgdGFyZ2V0OiBkb2N1bWVudC5nZXRFbGVtZW50QnlJZChcImFwcFwiKSxcbn0pO1xuXG5leHBvcnQgZGVmYXVsdCBhcHA7XG4iXSwKICAibWFwcGluZ3MiOiAiQUFBQTtBQUVPLHFCQUFjLEdBQW1CO0FBQ3BDLFNBQU8sSUFBSTtBQUFBO0FBR2YsTUFBTSxNQUFNLElBQUksSUFBSTtBQUFBLEVBQ2hCLFFBQVEsU0FBUyxlQUFlO0FBQUE7QUFHcEMsZUFBZTsiLAogICJuYW1lcyI6IFtdCn0K
Checking the base64
result above, the embedded D:
path isn't present, so vite
is adding it.
Thought I'd see if it was a quick fix. Good times. Lots of tests don't run on Windows at all.
Also fails to run tests under Windows Subsystem for Linux (WSL).
Should we assume vite
simply doesn't support Windows development, and that therefore we should avoid it if we need to support Windows?
We have a windows container running tests 🤔
So why tests are running there? Maybe we need to cover something about this if not already covered?
OK, using that as an example, tests seem to pass. Probably the difference was --runInBand
, but I nuked node_modules
and performed the exact steps in the CI config above.
So now I have a potentially working dev environment. Open question is whether I feel like putting the time in to fix the bug. I'll have to see what my schedule looks like.
It doesn't help that the repo that I converted to vite
doesn't seem to fully work, so even if I fix this there's still more to debug later. I was hoping to find an "easy" conversion from Parcel, since that project is in limbo between 1.x and 2.x and has been for a couple years it seems. But the build that works under Parcel doesn't work under vite
. Specifically, when the code tries to open a Socket.io connection, it never connects, so something to do with the Socket.io library? As a result I'm not sure if I want to spend the time to figure out why this isn't working.
The rabbit hole just gets deeper...
@Shinigami92 Looking at using Vite for another project now, and I have some free time. I'll dive in and see if I can track down why the path is so broken.
It looks like the philosophy of Vite is to make things Just Work by default, so I assume the preference would be to, on Windows, change the paths to be something that's correct, and not hide the change behind a new configuration option?
It looks like the philosophy of Vite is to make things Just Work by default, so I assume the preference would be to, on Windows, change the paths to be something that's correct, and not hide the change behind a new configuration option?
From what I know, yes, if it is possible to not hide something behind an option, I think it's always better ^^
I started on it, but in my experimenting I discovered that you can now debug correctly in Chrome and in Firefox. We're still seeing two copies of each file, but if you place the breakpoints in the "D:/" drive versions (as shown above) everything works as expected, or well enough to make no difference.
Given that meets my minimum requirements, I'm not going to try to poke at it any more for now. Paid work calls.
I have the same issue. My Sources Tab looks like the screenshots in https://github.com/vitejs/vite/issues/4657#issuecomment-905748549 Setting a breakpoint or using the stacktraces leads to the wrong line.
Looks like its fixed in vite 3 (tested with vite 3 beta 4). At least in my case
Describe the bug
Similar to #137 typsecript sourcemaps resolve to absolute full path when running live.
Reproduction
Which resolves to (Please note the absolute path):
Also in DevTools you see duplicate entries, which leads to some strange behavior at debug:
System Info
Used Package Manager
pnpm
Logs
Validations