[Bug] In-editor breakpoints broken because of source map discrepancies

[koushikkothagal]

🐞 Describe the Bug

The in-IDE debug/breakpoint experience for developers working on Ember apps is currently broken because of the difference in rendered source maps vs the source code in the code editor.

Example: For a component with a colocated template, like so:

import Component from "@glimmer/component";

export default class PeopleListComponent extends Component {
  constructor() {
...

The generated source map looks like so:

import { hbs } from 'ember-cli-htmlbars';
const __COLOCATED_TEMPLATE__ = hbs... <hbs contents and options here>
import Component from "@glimmer/component";

export default class PeopleListComponent extends Component {
  constructor() {

These extra two lines at the top of the source map pushes all lines in the component down, resulting in discrepancy in breakpoint line numbers. Breakpoints in browser's developer tools still work fine. But for breakpoints set in JS files in code editors (Example: VS Code) where the two lines don't exist, the line numbers don't match and the debugging experience is broken as a result

🔬 Minimal Reproduction

1. Create a component with template
2. Build and run with source maps
3. View generated component code with sourcemaps applied

😕 Actual Behavior

Viewing code with sourcemap applied shows two extra lines of code at the top of the component

import { hbs } from 'ember-cli-htmlbars';
const __COLOCATED_TEMPLATE__ = hbs... <hbs contents and options here>

🤔 Expected Behavior

Source maps should map exactly to the source the developer is working on

🌍 Environment

• Ember: - 3.17.0
• Node.js/npm: - v12.16.2
• OS: - macOS Catalina
• Browser: - Firefox andGoogle Chrome

➕ Additional Context

I have consistently verified this behavior for components, but I haven't looked at such possible discrepancies in other types of JS files like services and routes. I'll update this bug if I find more other occurrences of this issue beyond components.

[rwjblue]

This is ultimately a duplicate of these two issues:

• Invalid source maps generated ember-cli-babel#364
• Place colocated templates after the default export ember-cli/ember-cli-htmlbars#558

We can keep this one open as well (to help ensure folks can find the current investigation and whatnot).

The fix will almost certainly be over in ember-cli-htmlbars (doing something smarter with the string concatenation in the colocation build step).

[koushikkothagal]

@rwjblue Checking to see if there's any progress with this issue. I understand there was an attempted fix that didn't go through. Is there any other attempt planned to fix it the right way?
If not, is there another temporary workarounds we can implement to resolve this? Example: remove newlines from the prepended code that there's no line number offset? I think getting a good debugger experience in VS Code is a huge improvement in the developer experience, and I am happy to work with someone who has the bandwidth and knowledge of ember-cli-htmlbars.

[aberres]

We are also running into this issue and hoping for a workaround.

[bartocc]

In terms of tooling and DX, this would make a huge difference in our team. I am quite surprised that this issue does not attract more attention in the community 😞

[robclancy]

Just spent so long trying to get debuggers to work and it was once again another ember issue that is years old.

[bartocc]

@robclancy This issue is indeed old, but there is a path forward with First Class Template components and gjs files

See ember-cli/ember-cli-htmlbars#558 (comment)

[dmyoung9]

Assuming that a codebase is not prepared to fully migrate to the First Class Template style (as described here), is there just no solution for this?

It seems like there are lots of "proposed" ways of dealing with this, but they either break debugging in Chrome, do not fix debugging in VS Code, or both. In addition, code coverage reports are affected by these issues, with reported covered lines being offset from the actual source by 2 lines (or more).

So far, I have tried various different combinations of the following:

• Installing fast-sourcemap-concat==2.1.1, as described here
• Setting sourceMaps: 'inline'
• Setting sourcemaps: { enabled: true, extensions: ['js'] }
• Setting sourcemaps: { mapStyle: 'data' }
• Setting "sourceMaps": false in my VS Code launch configuration
• Installing @wagenet's version of ember-cli-htmlbars, as described here
• Fiddling with sourceMapPathOverrides (especially tricky when it comes to in-repo addons and/or engines)

Unforutnately, I am still completely unable to get either debugging or code coverage to work properly. Code coverage is accurate if and only if I use the forked version of ember-cli-htmlbars, but I have never been able to get debugging working in VS Code, with any combination of options, and many of the suggested options also break it in Chrome DevTools.

The closest I got to debugging in VS Code was to set "sourceMaps": false in my launch configuration, which appears to break at the right place, but requires debugging in the compiled monolithic source file, rather than in the actual source code.

My company's apps are built using multiple in-repo addons, in-repo engines, and privately maintained addons, and as such, our existing codebases are quite extensive already (even containing both Classic and Glimmer components, in many cases), so migrating large swaths of our codebase to First Class Templates is very overwhelming, especially considering the absence of proper debugging and coverage support.

Ideally, a solution would support proper source mapping, such that debugging can be leveraged in Chrome DevTools, VS Code, or even other projects leveraging a DAP architecture (like nvim-dap), and that code coverage reports are line-accurate.

Is this just a pipe dream at this point?

[kategengler]

cc @NullVoxPopuli I think I remember you working on source map accuracy at one point?

[NullVoxPopuli]

I believe the way to do this (this being: debugging in your editor instead of the browser dev tools (the browser devtools are where I debug, because it means I can re-set breakpoints / etc without leaving what I'm looking at -- the site/app)) is with our vite blueprint (which is currently pre-alpha), so that folks can follow these instructions: vitejs/vite#4065 (or rather, what someone figured out, as I could not find any "official" instructions to enable this for vite -- which is fair, it's all editor-specific stuff, usually.

For getting high-quality sourcemaps, for addons, best thing to do is migrate to v2 addons.
Getting high quality sourcemaps out of broccoli (v1 addons, pre-embroider apps) is very challenging, and ultimately not worth it (imo!!!) (since folks can just use the browser debugging -- which is very good / responsive / featureful / etc).

either break debugging in Chrome

just want to comment on this -- that specifics may be needed -- as this shouldn't be possible -- one of the reasons I like debugging in the browser is because it's less complicated. It's fewer tools involved than proxying the whole debug session back to the editor.

With Vite, if someone figures out how to set up their editor to be a debugging client, we should probably document that in our guides, because, as @dmyoung9 said -- lots folks out there just try things 🤷 would be good to get something definitive written down.

Once I get Vite in used in my work projects, I may explore this (in-editor debugging configuration) if my coworkers want it bad enough 😅

idk if this helps -- but it's the state of things.

---

PS: webpack sourcemaps are also very good