Hi Jacob, I’ve been using --experimental-specifier-resolution=node with loaders without issues for a while now (currently running 18.8.0) and it simplifies authoring. I was just wondering what exactly doesn’t work with loaders. Would love to see it supported if possible.
(It seems quite a few decisions lately come at the expense of making things more verbose for authors – e.g., import asserts. While these are mere annoyances for experienced developers, they make things harder to grasp for folks just learning a new platform.)
Lots of subtle things don't work. I don't know of a complete list—we don't track it because that feature has been deprecated for almost a decade (and will be removed in v19). It was a bad idea at the time, and it's still a bad idea now.
It's more like it makes the author experience lazier 😜 the ESM specification requires file extensions for good reason. It doesn't make anything harder to grasp: in most cases, you have a file on disk with an extension, so it's literally copy+paste, and if you don't, the error tells you exactly what you did wrong 🙂 imagine you're visiting your friend and you write down their address with everything but their house number. Can you find it? Probably eventually, but it's gonna suck looking. This problem is easily avoid, so avoid it 😉
Import asserts have a very specific reason as well: security. You can import from a remote source, eg example.com/config.json, but that doesn't necessarily mean you get json back—there is no rule saying the file extension there must be respected or even considered, so the server is perfectly justified returning whatever it wants. Json is not executable, but javascript is. That response could indeed be JavaScript instead; without the guard from the assertion (the assertion tells the runtime "this is not executable"), it would execute. Yikes, bad day. You CAN disable the safety of the gun you've pointed at your foot, if you really want 🤷♂️
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Jacob, I’ve been using
--experimental-specifier-resolution=nodewith loaders without issues for a while now (currently running 18.8.0) and it simplifies authoring. I was just wondering what exactly doesn’t work with loaders. Would love to see it supported if possible.(It seems quite a few decisions lately come at the expense of making things more verbose for authors – e.g., import asserts. While these are mere annoyances for experienced developers, they make things harder to grasp for folks just learning a new platform.)
Hiya Aral!
Lots of subtle things don't work. I don't know of a complete list—we don't track it because that feature has been deprecated for almost a decade (and will be removed in v19). It was a bad idea at the time, and it's still a bad idea now.
It's more like it makes the author experience lazier 😜 the ESM specification requires file extensions for good reason. It doesn't make anything harder to grasp: in most cases, you have a file on disk with an extension, so it's literally copy+paste, and if you don't, the error tells you exactly what you did wrong 🙂 imagine you're visiting your friend and you write down their address with everything but their house number. Can you find it? Probably eventually, but it's gonna suck looking. This problem is easily avoid, so avoid it 😉
Import asserts have a very specific reason as well: security. You can import from a remote source, eg example.com/config.json, but that doesn't necessarily mean you get json back—there is no rule saying the file extension there must be respected or even considered, so the server is perfectly justified returning whatever it wants. Json is not executable, but javascript is. That response could indeed be JavaScript instead; without the guard from the assertion (the assertion tells the runtime "this is not executable"), it would execute. Yikes, bad day. You CAN disable the safety of the gun you've pointed at your foot, if you really want 🤷♂️