Feature: Importing non-JavaScript files
GeoffreyBooth opened this issue · comments
An import statement can be used not just for JavaScript, but for JSON, WASM, .node, HTML and other formats in the future.
Use case 47.
As a maybe silly side note - all these issues are getting a little overwhelming. I want to read them all and think about them to make better choices when voting on things but there is a lot of them at once.
What would be the result of importing a HTML file? Or other files?
Would it be similar to fs.readFile?
What would be the result of importing a HTML file? Or other files?
That’s a great question. It was my use case (47) but my use case only mentioned JSON. The others got added in discussion during the meeting. Perhaps @jdalton or anyone else from the meeting can elaborate on the intent behind the other types of file imports?
If I had to guess, file types that Node knows how to execute (JavaScript, JSON, maybe WASM and .node) it would do so; and the rest would fail unless a loader had been registered? In other words, similar to require('index.html') today. Or maybe a better example would be require('app.coffee'), which works if the CoffeeScript loader is registered.
Yes, I agree with you.
If importing other file formats (ie no Node loader) results in a string, I don't see the use case for staticly declaring it.
Presumably future html modules (not the same as importing an html file) would provide something more useful than a string.
.... it's a bit difficult to read the official W3C documentation on these sorts of things, without reading the entire document for all the context.. so.. can someone summarize what the spec would do, if you told the spec to import a file that isn't a module?
pretty much anything that can be expressed as well-known values can be expressed with esm if someone tries hard enough
for the html example, the webcomponents team is trying to flesh out how chunks of html could be modularized and stuck together using esm
the wasm team is currently working on plugging the existing import/export structure of wasm into esm
anything that is specified by a large standards body should be implemented in node (to a point, like how node doesn't implement a dom)
This use case seems a bit unclear to me. Could we remove JSON, .node and wasm from the use case? I think it should be about importing any unspecified file format (I don't know about HTML).
Like, what should be:
import data from "./data.txt";pretty much anything that can be expressed as well-known values can be expressed with esm if someone tries hard enough
sure, and if I tell everyone my cat is a dog, eventually people will either go along with me, or think i'm nuts. :-)
Clearly, WebAssembly should have a method for exporting itself as modules. But, again, what would something that follows the spec do, if you attempted to import something that isn't even recognizable as a module? Or does the spec allow for defining modules as "whatever can be crammed into the definition" :-)
@ericblade I think that the case of WebAssembly is a bit different and already has its use-case. The specification of WebAssembly will include semantics to integrate well with JavaScript Modules.
sure, and if I tell everyone my cat is a dog, eventually people will either go along with me, or think i'm nuts. :-)
As a side note - the fact we say it should be possible doesn't mean we think it should be done by default.
If you specify a file extension that node doesn’t know how to parse, then i assume it would throw an error - a .txt file, for example, wouldn’t currently be importable or requireable.