How to add flow type definition for raw-loader

Recently I have encountered a quite odd problem. I was trying to load *.html file as a string in my React component using raw-loader , but have obtained flow error that flow can’t recognize this type of import. And here fun starts 😉 As I haven’t found anything straightforward about flow typing raw-loader I took a look at how this problem was solved for a much more common use case – CSS Modules. There are quite a few googlable ways how to fix this error for CSS Modules, so let’s see what they are, and what are downfalls of each way:

1. Use npm package `empty`

The fix should look like this one:

Source of the idea:

One of the most informative threads in the googleable area of the internet that I found about this type error originally was proposing this way to fix flow error for CSS modules https://gist.github.com/lambdahands/d19e0da96285b749f0ef. The difference is only, that for CSS Modules we are expecting object type as a result of the import, and for the raw-loader we are expecting the string to be imported.

Why not:

My main reason for not going this way was that I didn’t want to bring one more package in our project just to perform a fix, that looks like should be done more easily.

2. Resolve HTML import to its initial path and add extensions html as one of the possible extensions for files that flow should accept at import

The fix should look like this one:

Tech note: 

At first, this small piece of code can confuse, as it used not quite a typical way to write a regular expression. In .flowconfig   OCaml way to write RegExp is used. Check here to grasp better idea how this type of RegExp works http://caml.inria.fr/pub/docs/manual-ocaml/libref/Str.html#TYPEregexp

Why not:

I actually have ended up at some point with the thought that this should be a proper solution for this kind of problem. But (;)). Firstly, I have implemented it wrong and added the only resolvable extension html (as following module.file_ext=.html ) what have completely ruined flow on my project. Reason for this is that, if file_ext is not assigned any value explicitly it resolves to .jsx, .js, .json. But if it is assigned any value, it overrides these default extensions. Adding them as above should be the right way to solve it as well, but I end up with the feeling that I am with this change affecting all project configuration too much for such small fix, as it should be.

3. Add description by imitating type behavior of raw-loader

The fix should look like this one:

Why not:

It was the most tricky one for me personally, but the right answer is, that this just will not work if you placed raw-loader.js file in flow-typed folder. For me, it was totally a mystery for a couple of hours because I had no idea why I keep obtaining flow error, that Cannot resolve module "/flow-typed/raw-loader.js", even though this file exists in this exact place. Moreover, it confused me as this is quite a common suggestion to fix this error, but it hasn’t worked for me.

4. Add flow type declaration in flow-typed properly

The fix should look like this one:

Why not:

Actually, I end using this way to fix my flow, as from my perspective it felt as a most natural way to fix it.

Source of the idea:

After staring at the case that I have done as I mentioned upper for a few hours, and trying to understand why flow can’t see a file that actually exists in this place, I have checked other files that were in my flow-typed directory. And come up with the idea, that I should go for declaring separate type module for raw-loader and describe it, and resolve .html extension to it.

I believe I have read this example somewhere for CSS-Modules, but it was like 1 answer between hundreds other, and at a time when I am writing this post I even can’t find the original source of this one more time using Google.

From time to time I felt like I have the specific luck to end up fixing bugs, that, if to judge from Googling, wasn’t a problem for any other person, or were a too rare problem. What my previous such experience taught me, that even if it is not possible to google solution, it doesn’t directly mean that it is not possible to fix it. I even believe that there should be somewhere a good post about how to fix undocumented bugs ?. And one more good thing that can be done, is to write somewhere about your experience or in GitHub issues, on Gist example, on StackOverflow, or at least at your own blog 😉