Use plugin-requirejs in the jit-aurelia-cli example

[aurelia]

Use plugin-requirejs in the jit-aurelia-cli example

[EisenbergEffect]

I got it to work with the current CLI in our earlier repo...but I confess I forgot if I did anything special ;( It would be a bit different now that we have real packages though. I think we need to configure the view plugin in the config file.

[fkleuver]

It was mostly just complaining about not finding the plugin / file. Must be some small silly thing that I used the wrong path or file or something. It errors during page load (not during tracing)

[3cp]

The plugin works with current cli because amodro-trace uses requirejs runtime to trace, if you feed the plugin module to requirejs, it uses the plugin to rewrite the loading module.

But auto-trace cli doesn't use requirejs runtime to trace, then we need to replicate the plugin functionality in aurelia-cli/lib/build/loader-plugin.js (it only handles 'text' for now) to handle it at bundling time.

[3cp]

@EisenbergEffect The view plugin generates a very predicable templateSource. I talked with @fkleuver, why not we just enhance @customElment api to fill up the gap of templateSource?

[fkleuver]

Just speculating here, but I think it might be because of the convention. The plugin will get the name of the import and can name the element based on that. However @customElement will not get this information. So it would need an explicit name which would be unnecessarily verbose if the plugin could figure it out.

[3cp]

Could @customElement inspect the class name that it wraps? Use the same kebab case name for element name?

@EisenbergEffect does vCurrent figure it out using (abstracted) module loader by getting current module name?

[EisenbergEffect]

For vCurrent, there are no conventions inside the core runtime. So, you either need to explicitly provide the data or use AOT. In this case: https://github.com/aurelia/aurelia/blob/master/packages/examples/test-jit/name-tag.ts however, the plugin itself could pull the element name from the html file name itself (the module name minus the extension), since the plugin gets access to that.

[3cp]

No problem, we can bake this into auto-trace cli in future. I guess there will be equivalent plugins for parcel and webpack?

I don't think browserify allows you to do that, so browserify can only support inline view template.

[EisenbergEffect]

Yes, I was thinking we'd build plugins like this for each loader. It's a bit of work to support several of them but I think it's better for the framework if we keep that out of the core and instead delegate it to the bundlers/loaders.

[3cp]

This also means any 3rd plugin vNext plugin should be only allowed to build with AOT (or only inline view in jit) to avoid bundler dependency.

[EisenbergEffect]

Closing this as no longer relevant.