@joelanman Import type assertions are new, but that is going to be the "proper" way to do it with native ESM going forward. Otherwise the only option is to import filesystem.read and directly read the file. I don't consider it a step backwards; having oddities in Common JS such as being able to import non-JS files has always caused challenges with JS tooling. With import types, it's much easier for tooling to know exactly what it is the import is doing without having to guess.
@joelanman There's the usual reason: file extensions are only names and can't guarantee anything about what is in the file. Then there's JavaScript reasons, that take a whole lot longer to explain. So I'll throw it into a thread. 1/7
Node's implementation of Common JS is similar to other module systems. It expects that what you are importing is a text file that is another module, and then uses a Node-specific resolution algorithm to find the module. CJS imports are also done synchronously. 2/7
This means that Node was able to add unique syntactical sugar to imports: bare imports of JS files without extensions; bare imports using folder names as long as there's an index.js in the folder; synchronous in-line require; and specific support for files with .json extensions, where it will do the work of of parsing the file as JSON for you. 3/7
ES Modules are designed for the Web and use URIs as module specifiers. So the file extension has to be in the specifier because there isn't a really resolution algorithm outside of the URI indicating exactly where the file is. It can even be completely external using a web URL. So ES module imports are always asynchronous and can never assume the file type by the extension. 4/7
Like other module systems, ESM still requires the imported file be a text file that is another ES module. The problem is that in modern web-dev, people have many use cases for importing non-JS files; JSON and CSS being the prime examples. 5/7
In order to provide a way for a URI-based module system to import files that aren't modules in that programming language, you need to provide both the URI and an assertion of what kind of content is in that file. Then the run-time can choose to help you out in a standardized way, such as automatically parsing JSON files. 6/7
@joelanman Both require and import can be used as statements or dynamic functions. The statement syntax requires module import, but the function supports anything.
(Still talking ES6, don't know about Node specifically)
found another gotcha, you could use require to load json any time, import can only be used to load json in the root scope (not in functions for example)
Add comment