Debugging of Vite + Lit + TS problematic using VS Code.

[stefan505]

Describe the bug

I discovered that the default Vite + Lit + TS project has issues with hitting breakpoints set on the local TS source within VS Code, prior to starting the dev server:

1. Breakpoint set in code here:

2. Dev server started up, debugger instead breaks here:

This experience is extrapolated for any subsequent static or dynamic local TS module imports.

Upon further investigation, I discovered this strange behaviour within the browser sources:

1. A /src/my-element.ts file is exposed.
2. The content of the /src/my-element.ts file actually looks like transpiled JS, not TS.
3. The actual source file is derived based on the source map info at the bottom of /src/my-element.ts.

Observations:

1. There appears to be a "double source file" issue with this scenario that exists within the Vite dev server.
2. VS Code breakpoints set prior to starting up the dev server and importing the module, appears to hit and break against the first source file (The one located at /src/my-element.ts), instead of the second source file.
3. The actual error in question is somewhat obscured when setting breakpoints directly within the browser for a running dev server as both sets of source files are loaded and present. The browser dev tools appears to be able to "marshal" breakpoints and debugging to the correct source file.
4. Breakpoints set within VS Code after starting the dev server and loading the module do appear to behave correctly. I assume its because both source files are then correctly loaded, related to point 3 above.

I've searched through the Issues, Discussions and PRs and found several related pieces of info, but no clear solution is evident.

Reproduction

https://github.com/stefan505/vite-lit-ts-debug-repro

Steps to reproduce

1. Clone the repo.
2. Run npm i within the root.
3. Run code . within the root to open in VS Code.
4. Set a breakpoint on line 46 within the ./src/my-element.ts (the click handler). See screenshot above.
5. Press F5 to start up the JS debugger + browser launch.
6. Observe how VS Code breaks on line 17 unintentionally. See screenshot above.

System Info

System:
    OS: macOS 13.2.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 198.02 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 18.11.0 - /opt/homebrew/bin/node
    npm: 8.19.2 - /opt/homebrew/bin/npm
  Browsers:
    Chrome: 110.0.5481.177
    Firefox: 108.0.2
    Safari: 16.3
  npmPackages:
    vite: ^4.1.0 => 4.1.4

Used Package Manager

npm

Logs

No response

Validations

• [X] Follow our Code of Conduct
• [X] Read the Contributing Guidelines.
• [X] Read the docs.
• [X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• [X] 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 vuejs/core instead.
• [X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• [X] The provided reproduction is a minimal reproducible example of the bug.

[djarekg]

I also have then same issue. I have a monorepo, an app and several workspace dependencies. Breakpoints have the same problem for the app and for the workspace dependencies the breakpoints don't work all. If you look at the loaded scripts in vscode the source typescript files are loaded, but using vscode's breakpoint trouble shooting feature the source typescript mappings aren't resolved. If you open the typescript file from the loaded scripts it opens a version that you can set breakpoints in but it is not the original source file.

[D1no]

Updated to Vite from 4.1.4 to 4.2.1 and now breakpoints don't work anymore. pnpm mono-repo. Same problem with Vite 4.3.0-beta.1

Tested with VSCode and VSCode Insiders Build

[djarekg]

I too have a pnpm monorepo and vite looked promising when I switched over from @web/dev-server-esbuild. Everything in vite worked good and there's lots of customization you can do, but not being able to debug workspace dependencies for my lit project in vscode got extremely frustrating. Nothing I did could get it to work. So,I decided to create a new pnpm workspace project for my lit monorepo using @web/dev-server-esbuild and instead of using the one I was previously was using before I switched over to vite. And it was so easy to set up again from scratch, debugging from workspace dependencies just worked and it is blazing fast. And this time around I added @web/dev-server-hmr. So, now development is even faster.

Vite has a lot of documentation, but none of it is in depth. Perfect example is their config docs. All of it is high level documentation that just gives you a summary of each feature. And I love that there is a lot of examples in their example repo on GitHub, but there is no documentation or in depth comments explaining anything. A lot of stuff in those examples is not standard stuff, but specific to Vite. And if their documentation doesn’t cover it then how are we supposed to know. Some stuff is standard and others you can just follow but there is a lot that is not.

Modern Web doesn’t have in-depth documentation, but it isn’t needed. Especially bc their stuff follows the standards.

Vite was nice to use, but I felt like it was to rigid and that everything was too tightly coupled.

[D1no]

@djarekg see the issue linked right above your comment. #12743

And yes, I agree. There is a huge issue with End-To-End / Integration testing in Open Source. Claiming something works with pnpm for example, just because you did a pnpm install once is not the way to go. Same issue with Storybook, announcing pnpm support that "just works" but the reality is this: https://github.com/D1no/reproduction-storybook-symlinks-pnpm

[marcandreh]

We experience the same issue with our npm + lerna monorepo.

In vite 4.1.4 the VS Code Debug Diagnostics correctly show the source as ./packages/studio/src/pages/App.tsx ✅, whereas in vite 4.3.2 the source is incorrectly ./src/pages/App.tsx 🚫.

[sapphi-red]

This seems not to happen if the break point is set before the browser is opened.

1. npm run dev
2. Press F5 to start up the JS debugger + browser launch.
3. Set a breakpoint on line 46 within the ./src/my-element.ts
4. Click the button => break point works correctly
5. Reload the browser with Shift+Ctrl+F5
6. Click the button => break point works correctly

As it works properly if the break point is set after the browser is opened, I guess this is a bug in the VSCode debugger or Chrome. Maybe this is related to https://github.com/vitejs/vite-plugin-react/issues/179#issuecomment-1590710978

[sadovsf]

Possibly related issue: https://github.com/firefox-devtools/vscode-firefox-debug/issues/335