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

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.

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)

Got a PR for this up now, and also found a couple other small bugs / tweaks that will benefit Greenwood overall, be it regular resources or a frontmatter imports.

Thanks again for the report, will get this queued up for an upcoming alpha release in the v0.31.0 line. 👍

This does not appear to be fixed with the 0.31.0-alpha.0 tag

 grep greenwood package.json 
    "dev": "node --loader ./node_modules/@greenwood/cli/src/loader.js ./node_modules/@greenwood/cli/src/index.js develop",
    "start": "node --loader ./node_modules/@greenwood/cli/src/loader.js ./node_modules/@greenwood/cli/src/index.js develop",
    "build": "node --loader ./node_modules/@greenwood/cli/src/loader.js ./node_modules/@greenwood/cli/src/index.js build",
    "serve": "node --loader ./node_modules/@greenwood/cli/src/loader.js ./node_modules/@greenwood/cli/src/index.js serve"
    "@greenwood/cli": "~0.31.0-alpha.0",
    "@greenwood/plugin-google-analytics": "^0.31.0-alpha.0",
    "@greenwood/plugin-postcss": "^0.31.0-alpha.0",
    "@greenwood/plugin-renderer-lit": "^0.31.0-alpha.0",
    "@greenwood/plugin-typescript": "^0.31.0-alpha.0",
    ```

Yeah, the PR for this one hasn't been merged yet, alpha.0 was just to validate the first round of PNPM and import map changes, so will get this out for alpha.1 once I've had a chance to digest any compatibility issues with those changes across some of my projects, and to fully complete the work around #1313 / #684 .

I'm drafting the alpha.0 release notes as we speak.