Loading JSON file with ES6 import to browser

We use ES6 import without any build step. ES6 import doesn’t load json files due to HTML spec. So I am getting next error when loading index.es6.js: Failed to load module script: The server responded with a non-JavaScript MIME type of "application/json". Strict MIME type checking is enforced for module scripts per HTML spec.

So proper way will be to load javascript file which will export js object: https://stackoverflow.com/questions/34944099/how-to-import-a-json-file-in-ecmascript-6

[catamphetamine]

@brianreeve Well, ok, I’ll play along with their spec for now. Released libphonenumber-js@1.7.18, see if it works. I still consider the spec flawed.

[brianreeve]

Debating is fun and should be encouraged.

Thanks for your additional comments. I just meant that I wasn’t trying to be contrary or difficult in my challenges to your replies.

JSON is an extremely convenient and standardized data format across the whole world and so it would make perfect sense for the spec authors to add the ability to import json.

Not doing so is oppressing the minority that favours json over js.

I can appreciate your sentiment, but don’t agree with your assessment that minority opinions are being oppressed if they don’t make it into a spec. I don’t even think that being a fan of json puts anyone in a minority (I definitely like it), but I imagine spec authors must consider A LOT of external and internal factors when determining what makes it in.

More to the point, as written, the import spec and implementation is clearly not intended for anything other than javascript modules. Calling it “inferior” to webpack’s json-loader approach is not constructive. I would argue webpack’s importing of json is a misuse of the feature.

Depending on the use case, there are alternative solutions that are fairly simple, such as loading JSON data via XHR, or exporting an object as we’ve seen.

If the spec allowed importing non-js files, like json, then why stop there? Why not allow importing text files like csv, yml, or binaries like images, videos, etc.? As you can see it would quickly spiral into deeper implications with security, memory management, caching, etc. since there are already appropriate mechanisms in place to manage those.

Yeah, that’s the point: no one supports that new importing system of yours.

This is a bold statement. It has been in the spec since ECMAScript 2015 and is now very widely supported across browsers. Libraries are definitely shipping with using import.

The fact is the platform technology has properly plugged the holes which were previously patched through tooling and process. Since authors of the tooling are not required to follow any standard (or wrote the patchwork prior to specs being finalized), we’re now in a period where existing packages need to be adjusted to reconcile the differences and run as expected natively.

IMO, to resist that change is to resist forward movement.

metadata can be obtained by importing the .json.js files which can be generated from .json files by prepending export default to them. I could even see it being part of this library’s distribution package.

I don’t fully understand your proposed workaround you gave in your reply, but the above statement is in agreement with the last sentence of my previous post 💯.

ES6 support JSON importing with the following syntax: import * as data from ‘./example.json’

BTW, I did try this earlier and it fails with the same error as originally reported.

Regarding semver-compare, it does seem that it would be reasonable to inline or absorb into your project since it’s a single function. Just out of curiosity, is it necessary any more? It seems that you are only shipping one version of metadata, but the code supports 3 separate versions of the json?

I’m happy to test any changes you’re planning on implementing to support native module imports. I’m following this thread, so I’ll try to be responsive to test any updates.

Thanks.