Replacing `moduleName` in template meta about rfcs HOT 11 OPEN

glimmer vm is also probably passing it as the only template information. captureRenderTree items has a property ``template` which is the same as moduleName

from rfcs.

Isn’t the scope closure good enough?

from rfcs.

Sorry I should be more specific, I was responding to the need for a function to “point at” for jumping to the definition; scopeFn could serve that purpose rather than introducing one specifically for debug purposes only, right?

from rfcs.

Copying my comment from emberjs/ember-inspector#2425 (comment) here:

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)

from rfcs.

Today in the tooling meeting we discussed this and are generally in favor of trying to eliminate moduleName from <template> tag by default.

I looked around it seems like most places already assume moduleName could be undefined and generally have fallbacks like ?? (unknown module)

I propose that

1. we add a { moduleName = undefined } option to template()
2. for <template>, depending on how we feel about using the "attributes space", either

   <template moduleName="...">...</template>
   

   or

   // moduleName ...
   <template>...</template>
   

   (to be consistent with #982)
3. if it seems like it is important to have this for dev mode and/or backwards compatibility, we ship a babel plugin that adds back the above in a best-effort compatible way

from rfcs.

I don't think HMR should be using moduleName at all, it should just replace the imported value.

import Foo from "./foo";
import bar from "./bar";

<template>
  <Foo @foo="..." />
  {{bar "some" "args"}}
</template>

Should be transformed into something like

import { tracked } from "@glimmer/tracking";
import Foo from "./foo";
import bar from "./bar";

// TODO eliminate this when not import.meta.hot
const __imports__ = new (class {
  @tracked Foo = Foo;
  @tracked bar = bar;
})();

if (import.meta.hot) {
  import.meta.hot.accept('./foo', (Foo) => __imports__.Foo = Foo);
  import.meta.hot.accept('./bar', (bar) => __imports__.bar = bar);
}

<template>
  <__imports__.Foo @foo="..." />
  {{__imports__.bar "some" "args"}}
</template>

Then everything should just work.

from rfcs.

what about just "name"?

export const Foo = <template>

</template>;

gets transpiled to:

// ...
export const Foo = template('...', { name: 'Foo', /* ... */ });

no user-land customization?

from rfcs.

The point of the feature is for backwards compatibility anyway and I think we either try to preserve existing behavior as much as possible or not do it at all

from rfcs.

if you want it name-ed for some reason, just use a class:

class Foo { <template>...</template> }

That would naturally give you the .name property and you can use the normal pragma to tell the minifier to leave it alone (or not)

from rfcs.

it's just <template ...attribute space> would require more syntax work for some editors / tools, so my preference would be to only add something to attribute space if it's going to be a future-facing feature, rather than a backcompat one

from rfcs.

I think that space is spec-ed/reserved for content-tag, so it may need to happen anyway (e.g. depending on #982), but I agree I wouldn't do it just for this. So, IMO if we are using it for other things, then we should use it for this, otherwise the anything is fine.

That being said it does have its issues: e.g. what if you want to make it conditional based on import.meta.DEBUG. However, content-tag probably has to support that in general anyway.

from rfcs.