Placing file with `.htm` extension breaks the build

[gryzzly]

Describe the bug When placing foo/index.htm into public folder, build command produces an error. In development, this works fine – /foo/ correctly served as HTML

When running build, I get Unexpected token (Note that you need plugins to import files that are not JavaScript)

Changing file estension from .htm to .html fixes the problem.

To Reproduce Steps to reproduce the behavior:

1. Go to /public
2. Add a folder 'foo' and put index.htm into it with some html inside
3. Run npm run start and navigate to /foo/ in browser
4. Run npm run build and see error: Unexpected token (Note that you need plugins to import files that are not JavaScript)

Expected behavior I’d expect .htm to behave the same way as .html. Build successfully copies foo/index.html into dist

Desktop (please complete the following information):

• OS: macOS 10.14.6
• Browser: Firefox, Brave
• WMR Version 1.3.2

Additional context Not a huge deal, but showing an error about htm not being supported might save time for someone.

[developit]

I'm on the fence about this one - I don't know if we should support .htm as an extension given the fractional usage and also given that WMR already uses htm and that can be a little confusing.

That said, we should improve the error message for sure. It should say something like "you need at least one .html file in your public directory".

[gryzzly]

@developit in my case I have a proper index.html generated by wmr at creation of project – my use case was – I had an "admin" folder that is a self-contained "spa" that I copy over between the projects. It just happened to have .htm and it took a bit of time to find out it was these files that broke the build.

If it listed the "files that are not javascript" and respective file extensions I think it’d be clearer to understand what is going on.

I agree on the fractional usage, I realised the extension could be the reason quickly enough, but I also just had a few files and removing files from /public one by one proved that it was the admin folder that caused the trouble.

[danielweck]

Note that WMR expects the *.html extension in several code paths:

https://github.com/preactjs/wmr/blob/7e569dd23df6d599f0fb6c5a6a48b27e590a33fb/packages/nomodule-plugin/index.js#L35

https://github.com/preactjs/wmr/blob/7e569dd23df6d599f0fb6c5a6a48b27e590a33fb/packages/wmr/src/plugins/optimize-graph-plugin.js#L255

https://github.com/preactjs/wmr/blob/7e569dd23df6d599f0fb6c5a6a48b27e590a33fb/packages/wmr/src/lib/output-utils.js#L38

https://github.com/preactjs/wmr/blob/7e569dd23df6d599f0fb6c5a6a48b27e590a33fb/packages/wmr/src/plugins/html-entries-plugin.js#L37

https://github.com/preactjs/wmr/blob/7e569dd23df6d599f0fb6c5a6a48b27e590a33fb/packages/wmr/src/plugins/html-entries-plugin.js#L134

https://github.com/preactjs/wmr/blob/7e569dd23df6d599f0fb6c5a6a48b27e590a33fb/packages/wmr/src/plugins/html-entries-plugin.js#L149

[developit]

I mentioned it to Marvin offline, but I'll echo here: I'm 100% in for landing a proper error message here, but I'm waffling on whether to support .htm files. A tiny part of my reservation is just that .htm is an old DOS-style file extension that sees near-zero usage. However, my main concern is that it shares a name with htm, which is used by WMR - there's a potential confusion, but also it limits our ability to provide built-in support for loading .htm files (single-file components in the style of Svelte/Vue, but using HTM's syntax) in the future.

I'm the odd one out here, but if the above has convinced anyone, I think we could at least try landing the error message first - it's not just useful for folks saving .htm files, it would also help when folks have no HTML files in their public directory at all.

[marvinhagemeister]

For completeness sake copying my reasoning for adding .htm as .html files here too. Due to past experiences in my career I have strong feelings about aligning with existing standards.

I do quite like the appeal of having some form of single file components in the future. But I think the file name must not mess with established ones. For any word we'll chose we have to take the whole ecosystem into account. Every IDE will pick up .htm and treat it as an HTML file. Initially, I expect us to stay very close to HTML but I could see us adding a few syntax extensions here and there.

That will become quite problematic for language servers in Editors as any custom one for our file format needs to battle the builtin one. We've seen how this plays out a few times in the history of programming. In the JavaScript-sphere flow tried to overload the .js extension with their own syntax. This proved to be disastrous as both VSCode and Intellij didn't work with that and threw invalid JS errors left and right. Those two editors being the most popular ones with web developers meant that flow was essentially dead on arrival. TypeScript just worked out of the box and as usual people chose the path of least resistance/friction.

The same thing happened with TypoScript, a custom domain language of the TYPO3 CMS, which is pretty popular here in Germany. It uses .ts as an extension and that obviously clashes with TypeScript. To this day there is no solution to this other than to wrangle with editor project settings in hopes of getting it working. I had to deal with that for years in previous jobs. It was a shitshow and it still is today, because no editor can deal with that properly without having to mess around with its settings.

So yeah, I don't want to relieve those years. In my opinion overloading existing file format extensions is a huge can of worms nobody should open. It renders anything dead on arrival because fighting existing consensus, editor defaults, webserver defaults, etc is a lost cause. It's not worth it. Therefore we should support .htm the same way as .html and pick another file extension for any custom format we may go with.