Support Importing components via frontmatter in any format supported by any plugin

[lschierer]

Type of Change

Feature

Summary

the imports field in the frontmatter filters out any files that are not .js and not .css, please support any format supported by any Adapter plugin.

Details

I noticed this trying to import a typescript component in a project that has the typescript plugin enabled. the component works fine if included via layout, and also works fine if included by another component. If however, I attempt to use the imports field, then the corresponding script tag is not generated and the component does not hydrate, it gets processed as an unknown tag.

[thescientist13]

yeah, this seems like probably just an oversight and at a quick glance, probably not specific to TS, just anything not a .js or .css file, but agreed, Greenwood should certainly make sure any resource type supported by a resource plugin also carries support for it in frontmatter imports

[lschierer]

I'm looking at the TypeScript source plugin ATM, and I think a generic solution to this would entail the core application, as a new source plugin is registered, adding its "this.extensions" property to some more central global array of acceptable extensions that it filters the files in the front matter imports by. This is me hypothesizing from what I'm seeing in the code so far at least.

[thescientist13]

Yup, pretty much.

Taking a quick look now, frontmatter imports are processed starting here in the getAppLayout function, where we just filter on extension, so that's where we would want to open up embedding <link> and <script> tags to more than just .js and .css extensions. Greenwood does processing like this by pulling all plugins out of compilation.config.plugins and checking instances of plugins in the way you describe, e.g. like this, though I for this case we wouldn't need to actually process these files; we just need to check their contentType make sure there is at a plugin to handle it (be it application/javascript or text/css I think. Or maybe just grab all the extensions as you said, which is what we do to enable watch mode for the dev server for custom resources.

I think it might also need to be handled in the modelResource function as well, which has similar hardcoded check, but not 100 positive, but would probably be the same logic.

(also, just a minor technical point, but the TypeScript plugin is technically a resource plugin)