Typescript sourcemaps resolve to absolute full path when running live

[peterbud]

Describe the bug

Similar to #137 typsecript sourcemaps resolve to absolute full path when running live.

Reproduction

$ npx create-vite-app
$ npm i
$ echo "console.log('test')" > src/test.ts
$ echo "import './test'" >> src/main.js
$ npm run dev

$ curl 'http://localhost:3000/src/test.ts'                                                                                        
console.log("test");

//# sourceMappingURL=data:application/json;base64,eyJ2ZXJzaW9uIjozLCJzb3VyY2VzIjpbIkM6L1RFU1Qvdml0ZS1zb3VyY2VtYXAvc3JjL3Rlc3QudHMiXSwic291cmNlc0NvbnRlbnQiOlsiY29uc29sZS5sb2coJ3Rlc3QnKTtcclxuIl0sIm1hcHBpbmdzIjoiQUFBQSxRQUFRLElBQUk7IiwibmFtZXMiOltdfQ==

Which resolves to (Please note the absolute path):

{"version":3,
"sources":["C:/TEST/vite-sourcemap/src/test.ts"],
"sourcesContent":["console.log('test');\r\n"],
"mappings":"AAAA,QAAQ,IAAI;",
"names":[]}

Also in DevTools you see duplicate entries, which leads to some strange behavior at debug:

System Info

System:
    OS: Windows 10 10.0.19043
    CPU: (8) x64 Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz  
    Memory: 3.87 GB / 15.78 GB
  Binaries:
    Node: 16.3.0 - C:\Program Files\nodejs\node.EXE        
    Yarn: 1.22.10 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 7.15.1 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.19041.1023.0), Chromium (92.0.902.73)
    Internet Explorer: 11.0.19041.906
  npmPackages:
    vite: ^2.5.0 => 2.5.0

Used Package Manager

pnpm

Logs

vite:config no config file found. +0ms
  vite:config using resolved config: {
  vite:config   root: 'C:/TEST/vite-sourcemap',
  vite:config   base: '/',
  vite:config   mode: 'development',
  vite:config   configFile: undefined,
  vite:config   logLevel: undefined,
  vite:config   clearScreen: undefined,
  vite:config   server: { fs: { strict: undefined, allow: [Array] } },
  vite:config   configFileDependencies: [],
  vite:config   inlineConfig: {
  vite:config     root: undefined,
  vite:config     base: undefined,
  vite:config     mode: undefined,
  vite:config     configFile: undefined,
  vite:config     logLevel: undefined,
  vite:config     clearScreen: undefined,
  vite:config     server: { fs: [Object] }
  vite:config   },
  vite:config   resolve: { dedupe: undefined, alias: [ [Object], [Object] ] },
  vite:config   publicDir: 'C:\\TEST\\vite-sourcemap\\public',
  vite:config   cacheDir: 'C:\\TEST\\vite-sourcemap\\node_modules\\.vite',
  vite:config   command: 'serve',
  vite:config   isProduction: false,
  vite:config   plugins: [
  vite:config     'vite:pre-alias',
  vite:config     'alias',
  vite:config     'vite:modulepreload-polyfill',
  vite:config     'vite:resolve',
  vite:config     'vite:html',
  vite:config     'vite:css',
  vite:config     'vite:esbuild',
  vite:config     'vite:json',
  vite:config     'vite:wasm',
  vite:config     'vite:worker',
  vite:config     'vite:asset',
  vite:config     'vite:define',
  vite:config     'vite:css-post',
  vite:config     'vite:client-inject',
  vite:config     'vite:import-analysis'
  vite:config   ],
  vite:config   build: {
  vite:config     target: [ 'es2019', 'edge88', 'firefox78', 'chrome87', 'safari13.1' ],
  vite:config     polyfillModulePreload: true,
  vite:config     outDir: 'dist',
  vite:config     assetsDir: 'assets',
  vite:config     assetsInlineLimit: 4096,
  vite:config     cssCodeSplit: true,
  vite:config     sourcemap: false,
  vite:config     rollupOptions: {},
  vite:config     commonjsOptions: { include: [Array], extensions: [Array] },
  vite:config     dynamicImportVarsOptions: { warnOnError: true, exclude: [Array] },
  vite:config     minify: 'terser',
  vite:config     terserOptions: {},
  vite:config     write: true,
  vite:config     emptyOutDir: null,
  vite:config     manifest: false,
  vite:config     lib: false,
  vite:config     ssr: false,
  vite:config     ssrManifest: false,
  vite:config     brotliSize: true,
  vite:config     chunkSizeWarningLimit: 500,
  vite:config     watch: null
  vite:config   },
  vite:config   env: { BASE_URL: '/', MODE: 'development', DEV: true, PROD: false },
  vite:config   assetsInclude: [Function: assetsInclude],
  vite:config   logger: {
  vite:config     hasWarned: false,
  vite:config     info: [Function: info],
  vite:config     warn: [Function: warn],
  vite:config     warnOnce: [Function: warnOnce],
  vite:config     error: [Function: error],
  vite:config     clearScreen: [Function: clearScreen],
  vite:config     hasErrorLogged: [Function: hasErrorLogged]
  vite:config   },
  vite:config   createResolver: [Function: createResolver],
  vite:config   optimizeDeps: { esbuildOptions: { keepNames: undefined } }
  vite:config } +6ms
  vite:deps Hash is consistent. Skipping. Use --force to override. +0ms

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[hyf0]

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

[TimMensch]

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:

1. npm init vite@latest (Note: the yarn create vite doesn't work if you have Node 14 installed. 👎)
2. Select svelte
3. Select svelte-ts
4. yarn
5. 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?

[TimMensch]

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.

[TimMensch]

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?

[Shinigami92]

We have a windows container running tests 🤔

vite/.github/workflows/ci.yml

Line 24 in 99a35b2

- os: windows-latest

So why tests are running there?
Maybe we need to cover something about this if not already covered?

[TimMensch]

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...

[TimMensch]

@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?

[Shinigami92]

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 ^^

[TimMensch]

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.

[MichaelFroeschen]

I have the same issue.
My Sources Tab looks like the screenshots in #4657 (comment)
Setting a breakpoint or using the stacktraces leads to the wrong line.

[MichaelFroeschen]

Looks like its fixed in vite 3 (tested with vite 3 beta 4). At least in my case