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

• https://github.com/babel/ember-cli-babel/issues/364
• https://github.com/ember-cli/ember-cli-htmlbars/pull/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 https://github.com/ember-cli/ember-cli-htmlbars/pull/558#issuecomment-1238117628