Skip to content
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

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

Open
7 tasks done
stefan505 opened this issue Mar 2, 2023 · 7 comments
Open
7 tasks done

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

stefan505 opened this issue Mar 2, 2023 · 7 comments
Labels
bug: upstream Bug in a dependency of Vite feat: sourcemap Sourcemap support p3-minor-bug An edge case that only affects very specific usage (priority)

Comments

@stefan505
Copy link

stefan505 commented Mar 2, 2023

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:
    image

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

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:
Screenshot 2023-03-02 at 13 42 17

  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

@stefan505 stefan505 changed the title Debugging of TS problematic using VS Code. Debugging of Vite + Lit + TS problematic using VS Code. Mar 2, 2023
@djarekg
Copy link

djarekg commented Mar 23, 2023

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
Copy link

D1no commented Apr 4, 2023

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
image

Tested with VSCode and VSCode Insiders Build

@djarekg
Copy link

djarekg commented Apr 6, 2023

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
Copy link

D1no commented Apr 7, 2023

@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
Copy link

marcandreh commented May 25, 2023

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 sapphi-red added the feat: sourcemap Sourcemap support label Jun 14, 2023
@sapphi-red
Copy link
Member

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 vitejs/vite-plugin-react#179 (comment)

@sapphi-red sapphi-red added bug: upstream Bug in a dependency of Vite p3-minor-bug An edge case that only affects very specific usage (priority) labels Sep 28, 2023
@sadovsf
Copy link

sadovsf commented Jun 26, 2024

Possibly related issue: firefox-devtools/vscode-firefox-debug#335

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug: upstream Bug in a dependency of Vite feat: sourcemap Sourcemap support p3-minor-bug An edge case that only affects very specific usage (priority)
Projects
None yet
Development

No branches or pull requests

6 participants