Option to guess at better pathings?

[NullVoxPopuli]

Is your feature request related to a problem? Please describe. Was just poking around and noticed this: that path for the component is just hilarious -- almost goes across my whole screen lololol

Describe the solution you'd like

Maybe an option in the inspector settings to provide the module path, rather than path on disk?

Describe alternatives you've considered keep it silly

[patricklx]

what could be the best way here? The nicest one would be to check for 'node_modules' and if its there, take the path part after it. But that would also no be entirely correct, so maybe take the last part to show as template path and add a tooltip to show the full path?

though embroider should already take care of the leading path to app dir: https://github.com/embroider-build/embroider/blob/main/packages/shared-internals/src/hbs-to-js.ts#L30.

or should this be fixed in embroider to ouput the same as classic builds? edit: might also be ember-template-imports doing it? edit2: "right, ember-template-imports could fix this by passing in moduleName here like ember-cli-htmlbars edit3: found also this: https://github.com/emberjs/babel-plugin-ember-template-compilation/blob/main/src/plugin.ts#L296

so, the goal is to have moduleName be the real path? however i would argue that that is not a moduleName then. or at least not a useful one with all the linking in between...

also, I also do not see a way to remove the leading path to the root dir... I think this should really be fixed in embroider and ember-template-imports

[ef4]

The key question here is: why do we think templates need this special form of debugging info to point back at their source, when we don't expect the same from every javascript module?

That distinction used to make sense, because templates used to be entirely separate from javascript. But now they are just values inside javascript. moduleName isn't even enough to uniquely locate a template anymore, given that you can have dozens of template tags in one module.

The inspector feature here should be more like a "jump to source" button. If instead of embedding moduleName next to each compiled template we instead embedded a tiny function:

t.createTemplateFactory)({
        id: "efyYydg8",
        block: '[[[8,[39,0],null,null,null]],[],false,["four-oh-four"]]',
-       moduleName: "pdpm-calc/templates/404.hbs",
+       debugHandle: function() {},
        isStrictMode: !1
    })

then at runtime the inspector can do window.inspect(theComponent.debugHandle) and it will immediately open the Sources pane of the dev tools pointing directly at the right component.

(I think it has to be a function because window.inspect is good at jumping to sources of functions, but it can't necessarily do the same for other kinds of objects.)

[RobbieTheWagner]

@ef4 I would be open to that.

[patricklx]

@ef4 good idea, but then moduleName should not be set if nothing is passed to the template compiler. Currently the template compiler sets it to a filename

[ef4]

I'm creating an RFC issue to centralize discussion of this problem: https://github.com/emberjs/rfcs/issues/940

[lifeart]

Wee may still need moduleName to support hot module replacement for components (in vite), at the moment we map changed component files to rendered components by moduleName resolved from getComponentTemplate or component itself. (https://github.com/lifeart/demo-ember-vite/blob/master/plugins/hot-reload.ts#L169)