Tests are failing, not sure what's wrong, I just see massive diff failures that look unrelated to what I changed.

Woah, when did you switch to @kittens?

I think I'm not quite following your use case. Can you give an example? It doesn't sound like your talking about a situation with both a main and a flow:main like

{
  "main": "src/transformed_index.js",
  "flow:main": "src/original_index.js",
  ...
}

since this doesn't seem to save you any build trouble. And it's not clear to me why you would have flow:main without a main.

Your OCaml looks good, though!

As for tests, I can look when Travis finishes. The incremental script runs this bash script which moves the various files around, making sure that Flow's incremental mode follows the changing. That's probably one source of issues.

@gabelevi

Woah, when did you switch to @kittens?

Few weeks ago 😛 It removes the confusion and accidental mentions with the other Facebook JavaScript React Sebastian.

I think I'm not quite following your use case. Can you give an example? It doesn't sound like your talking about a situation with both a main and a flow:main like

I'm actually talking about that situation exactly. I recently published kreporters which uses Flow types and there's only a few ways I can get third party consumers to use the types and they all aren't great:

• Flow comments: Doesn't support classes which I'm using and the transformations aren't complete lossless so there's a lot of information lost and Flow sometimes doesn't actually understand it.
• .flow: I'm not using a build system. I just use the Babel CLI like $ babel src --out-dir lib. I could switch to Gulp or Grunt to do my builds but that seems like overkill for such a small library. The equivalent shell command would probably be $ find src -name ".js" -exec cp src/{} lib/{}.flow \;, but that seems pretty gnarly and it wont work on Windows.
• Interface: Provide an interface file and make someone copy it to their project. I'd need to maintain this separately from the typed files and it's very manual and only suitable for projects that aren't typed.

Also just want to highlight that having this ability means that libraries can provide type information without any changes to their build system. For example you just have to remove src from .npmignore and add "flow:main": "src/index.js" to your package.json.

Ah ok, I get it. The requirement of putting foo.js.flow next to flow.js is inconvenient and it's much easier to tell node to read lib/ and flow to read src/.

Yeah, this makes sense to me. I'd merge this once the tests pass :)

how does this compare to the typings key TypeScript uses? is there really any value to being able to flow:-prefix every key? do other projects use : as namespaces?

an alternative would be { "flow": { "main": ... } }. another thing we might put under the flow key would be something like .flowconfig's module.name_mapper so that you can map require('foo/lib/derp') to foo/src/derp.js

@mroch

how does this compare to the typings key TypeScript uses?

You still need to point to an interface file as far as I know. This would allow you to point at your original source and have Flow point to that instead of some random location in lib.

is there really any value to being able to flow:-prefix every key?

Not really, the only other key that's used is name. Figured it was more future proof to do it for any key to support it automatically in the future.

do other projects use : as namespaces?

jsnext:main is used by all the major module bundlers that support ES2015 modules. It's used to provide an alternate ES2015 build that they can consume while main still points at a CommonJS build. For example here are the rollup docs.

an alternative would be { "flow": { "main": ... } }

Keys used like that in package.json are historically used for build config. For example Babel uses a field called babel and ava uses ava. So it would seem more appropriate for the flow namespace in package.json to be analogous to .flowconfig. There's also precedence with jsnext:main to prefix main with a namespace.

Actually looking into typings more, it does appear to be the same as flow:main as it can consume arbitrary typed files too. I think there's a compatibility hazard with using it though unless Flow supports all the TypeScript syntax.

an alternative would be { "flow": { "main": ... } }

This was my initial thought too, but I settled on the idea that flow:foo was good for overriding the value of foo for Flow while "flow": { ... } would be good for flow specific stuff (like .flowconfig stuff) if we decide to allow any of it in the package.json

Just an update, I'm still going to work on this PR. Should have addressed all the comments and have tests passing next week.

I'm gonna close this to clean up the queue since it's stale, but obviously feel free to resurrect it

Shame to see this closed, we're using https://github.com/AgentME/flow-copy-source in some cases but for rollup builds et al it would be much better/easier to have a flow:main.

I've opened #2675 so this can be discussed and eventually fixed :)