Importing html not working. Cannnot use with custom plugin or build either.

[brandonseydel]

I have tried to pass to my custom plugin and it never does either.
"plugin:ts": "./plugin.js"
"plugin:html": "./plugin.js"
"plugin:ts,html": "./plugin.js"

[FredKSchott]

Snowpack should be building your file properly, but right now we only support the following two non-JS imports:

• https://www.snowpack.dev/#importing-css
• https://www.snowpack.dev/#importing-images%2C-assets

What's your use-case here / what behavior are you expecting? Would love to make this work for you.

[brandonseydel]

I am on the aurelia core team and we are trying to build out an official template. I have successfully ran code through our custom plugin but the default method of import is to import template from './my-html.ts' This leads us to aurelia free code. We can explicitly set the values to a string, but most our users want the very simple non import version.

[brandonseydel]

manually users can do this no problem
@customElement(name:'test', template: '<div></div>')
export class Test

// but the plugin is this
export class Test

// which generates
import template from './test.html'; 
@customElement(name:'test', template)
export class Test

[brandonseydel]

you want me to tackle this or is this something you guys can take on fairly easily?

[FredKSchott]

When you say tackle, are you able to do this in your plugin?

// input
compile `export class Test`

// output
@customElement(name:'test', template: '<div></div>')
export class Test

If so, I'd say yes. We're trying to be very limited in our support for importing non-JS files. We will probably need to support customizing this one day, but for where we are at today it's a bit out of scope. Happy to get creative here tho to make this use-case work for you.

[fkleuver]

We're trying to be very limited in our support for importing non-JS files

What about HTML modules when they make it into the spec / are implemented?

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/HTMLModules/explainer.md
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/ewfRSdqcOd8/w_Fr6rJ3DQAJ

[FredKSchott]

It's still too early as a spec to be supported by default (when it changes, we'd have to change all users) BUT I'm definitely not opposed as an opt-in plugin when we get the plumbing in place for a good plugin system.

[fkleuver]

It's still too early as a spec to be supported by default (when it changes, we'd have to change all users)

Fair enough! I was just curious whether your stance on support for importing non-JS files was based on design principle or based on the current status of the standards. I take from your message that it's due to the latter.

[fkleuver]

Just thinking out loud here, could it be an idea to make a MIME-based protocol as a fallback for non-JS (or otherwise non-specced) file types? As an explicit opt-in, so that when something makes it into the spec as a new module type, you would still be spec compliant by default.

You could stick to standardized MIME types with known extensions (such as those aggregated in this database), and use that to transform file content to an export default with a raw string (in the case of UTF8) or otherwise as an ArrayBuffer.

Then, there is still the issue of webpack having import * as someResource syntax which would be incompatible with export default, but that could technically also be solved with a simple import rewrite (e.g. import * as someResource => import { default as someResource })

Or would that be opening a can of worms for snowpack?

[FredKSchott]

It sounds like you're describing something close to the same goals as this proposal: https://github.com/tc39/proposal-module-attributes

[fkleuver]

Yep, I was actually (implicitly) referring to that spec. So I was thinking along the lines of a non-conflicting polyfill. However it's understandable if you prefer to just go with stage 3 & higher proposals.

[FredKSchott]

Yup, I'm sure this is what we go with eventually but its just too early to support now (or, there was also an asset proposal that would let you do things like import asset './foo.html'. Not sure if that's made any progress tho).