Same case for .vue (Vue.js) components. There's a nasty workaround in Vue that'll make it work atm (using comments):

/* @flow
<template>...</template>

<style>...</style>
*/

// <script>
...
// </script>

It's nasty to say the least & it might break in a future release of Vue. If Flow could parse the <script> tag all of this will go away.

+💯

For reference, there is a plugin for ESLint called eslint-plugin-html that enables it to lint HTML files.
Perhaps something similar could be developed for Flow.

Any progress on it? Vue is more and more popular, it should be nice if a solution à la eslint-plugin-html could be added to Flow... Perhaps like an option?

Has any progress been made on this, or is anyone working on it? This feature is the only thing preventing me from using Flow.

Is this a possible workaround for vue components?
Seperate .vue files at the beginning and let them act as kind of "loader" for .js and .html files like in this vue 2.0 boilerplate. It's this way not ugly looking comments.

Example .vue file:

<template src="./index.html"></template>
<script src="./index.js" lang="babel"></script>

and place your index.html and index.js (with your vue code) file in the same directory (let flow ignore .vue).

That should be fine for standalone, but it won't work for the runtime-only build.

a workaround for runtime is babel-plugin-tcomb. Explanation here http://stackoverflow.com/a/40130503/756056

You actually can use flow with vue.

module.exports = {
  "extends": [
    "standard"
  ],
  "plugins": [
    "html",
    "flowtype-errors"
   ],
   "rules": {
      // raise flow errors
      "flowtype-errors/show-errors": 2
   },
   "parser": "babel-eslint",
   "parserOptions": {
     "ecmaVersion": 2017,
     "sourceType": "module"
    }
}

Here's the full example: https://github.com/wemake-services/wemake-vue-template

JS in HTML is a complicated issue. It potentially necessitates a whole new way of building dependency graphs and also introduces the concept of a cross-file global environment.

@mrkev what you mean by cross-file global environment, isn't this already exists with declare var?

@goodmind I mean the implicit window. I guess it's not necessary per-se, but I was just wondering how we could build a dependency graph with a different way of handling imports/exports.

@mrkev would this require some OCaml HTML parser? jsx parser is not good for html files

@goodmind probably that too for inline JS, yeah.