New library definitions approach

[goodmind]

Proposal

Support .js.flow files as new library definition format

Main Proposal

https://github.com/goodmind/flow-new-libdef-approach/

Alternative? Not sure about multiple files then

Enable @providesModule for select directories with section (doesn't matter which resolver is choosen node or haste)
Support @scoped/package for @providesModule

[provides_modules]
node_modules/@flowtyped

Use case

flow-typed migration to NPM

[nmote]

We've discussed this in Discord and I think this sounds like a good approach. I am particularly interested in the *.js.flow file portion, which will have the following advantages:

• Easy to generate (we basically have the infrastructure for this now, it's just a matter of hooking it up to a CLI command)
• Flow treats them as implementation files, so when they change they don't require a restart, unlike libdef files (and this would be tricky to fix for libdef files)
• They have fewer weird pitfalls, since they are just ordinary implementation files. IMO they are easier to write manually. You just write your normal JS except you can use declare function etc. to avoid providing the bodies of things. For example, everything you declare in a libdef file is considered exported, which can be kind of annoying if you want helper types or something that aren't actually exported.
• You can more accurately model requires because .js.flow files follow ordinary node module resolution while libdefs just make a module globally available.

The necessary changes to Flow itself are:

• A feature added to support the flow.name field in package.json (possibly restricted to only node_modules/@flow-typed directories). This is only necessary for the *.js.flow portion of the proposal.
• A bug fix to Flow to avoid issuing parse errors when .json files are encountered in libs directories (Ignore json in [libs] section #7746). This is only necessary for the libdefs portion of the proposal.

[chrisdothtml]

I know this is an old PR, but what are the implications of this for a pnp system (e.g. yarn v2)? Since it doesn't use node_modules, currently the only way to get flow to work with pnp is via libdefs, so if libdefs were moved from flow-typed to node_modules that would remove all possibility of using flow with pnp

[nmote]

If something like this does move forward, I would expect it to be possible for the flow-typed CLI tool to pull down the necessary libdefs. Flow can be configured to look at places besides node_modules so perhaps we could standardize on putting libdefs if node_modules_libdefs or something. Then, PnP could proceed as normal. At runtime, the node_modules_libdefs folder would be ignored, but Flow would be able to use it when looking up the types of modules.

We still aren't planning on adding specific support for PnP in the foreseeable future, and this particular proposal doesn't have anybody working on it, either. But I don't think this would make it substantially harder to use PnP.