Treat imported JSON as typed literal

[TiddoLangerak]

When importing a JSON module it seems that flow treats its value as an any type. It would be great if flow would instead treat it as a typed literal, just like it would if the given object was inlined. E.g.

//obj.json
{
  "val" : "sadf"
}

//index.js
import obj from 'obj.json';

function double(x : number) {
  return x * 2;
}

// $ExpectError
double(obj.val);
// $ExpectError
obj.nonExisting;
// $ExpectError
const key : $Keys<typeof obj> = 'notAKey';

[asolove]

This would be somewhere between very tricky and impossible to get right, especially in cases where arrays contain objects of different shapes.

When I do this in my own code, I usually already have types that I expect the file to match and just do a cast, like this:

let typedDate: {val: number} = obj;

And if you have reason to doubt the file is correct, then write a function that parses the imported data, asserts that it's in the shape you want, and then returns it with the right type.

[vkurchatkin]

There is not much tricky about it, since Flow already does this for literals. The problem is that JSON files can be very large, so this feature could affect performance greatly.

[TiddoLangerak]

Like @vkurchatkin said, I expect this to work the same as for literals, i.e. that flow would treat JSON files as if they were JS files with a single default export (in fact, my current workaround actually is to have a build step that prepends the json file with export default).

Manual typing is only a solution for a subset of JSON usages. E.g. i18n bundles are often written in JSON format. If flow could infer their types then it could assert that only existing keys are used. Explicitly creating a type might catch incorrect usages from JS, but it still doesn't guarantee that the .json and the type matches (and in the case of i18n, it also results in a huge type that you need to maintain manually). Asserting the shape at runtime isn't a solution here either: firstly it completely defeats the purpose of a static type checker, and secondly it introduces yet another duplication of all the keys in a bundle, with yet another chance of making mistakes that flow won't be able to catch.

With regards to performance: if performance is a significant issue then flow could provide an option in the .flowconfig to opt-in/opt-out of the feature.

[wips]

Just to draw some more attention here. Such feature would be useful for our project as well

[STRML]

TS just added this: https://blogs.msdn.microsoft.com/typescript/2018/05/31/announcing-typescript-2-9/#json-imports