Flow-typed: Publish libraries as npm packages

[DullReferenceException]

I'm a first-time FlowType developer who has experience developing with TypeScript. One thing that the TS community did well, IMO, is the DefinitelyTyped set of installable packages. Rather than using a separate CLI tool to install types (like flow-typed), you can simply do this, for example:

npm i --save-dev @types/axios

The nice thing about using regular dependencies is that you get all the same behaviors for free, like sub-dependencies, npm prune --production, shrinkwrapping/lock files, etc.

Is there a reason why the types maintained in this repository are not installable via typical packaging tools like npm or yarn? Has this been considered?

[TrySound]

+1 I don't able to use external git requests. Npm uses artifactory as proxy.

[marudor]

I think @jeffmo @thejameskyle could answer this.

[jamiebuilds]

The problem right now is that we need to match against three different versions:

• The version of the library
• The version of flow the libdef was written for
• The version of the libdef itself (for fixes)

Maybe it'd be possible if Flow could match against versions inside of these published packages.

Imagine this file structure for a package @flow/library-name:

/node_modules/@flow/library-name/
  library-name-flow_v0.28.x-v0.30.x.js
  library-name-flow_v0.30.x-v0.38.x.js
  library-name-flow_v0.38.x-.js
  package.json

If Flow could select which version it used based on either the file name or maybe some configuration in package.json:

{
  "name": "@flow/library-name",
  "version": "1.0.0",
  "flow": {
    "v0.28.x-v0.30.x": "library-name-flow_v0.28.x-v0.30.x.js",
    "v0.30.x-v0.38.x": "library-name-flow_v0.30.x-v0.38.x.js",
    "v0.38.x-": "library-name-flow_v0.38.x-.js"
  }
}

Then we could ship these to npm and use other package managers.

For updates to a single libdef maybe we could expand on the version:

{
  "name": "@flow/library-name",
  "version": "1.0.0-0",
}

That doesn't seem great though... maybe there are other options.

[EdwardDrapkin]

Sorry if I'm speaking out of turn, but why not only allow the libdefs to handle Flow support themselves? It seems like it would solve the underlying issue here - libdefs could be versioned based on the library version with something like 0.0.0-1.0.0 and 0.0.0-2.0.0 to denote libdef versions.

When there's a breaking change in Flow, endusers (like me) will have the option to pin to a specific version of a libdef if we don't want to also update Flow. If there are packages that currently have multiple implementations suitable to different versions of Flow, I'd say check them in as versions -0.0.1, -0.0.2, etc.

Basically what I'm saying is why not delegate the Flow versioning to the npm package for the individual libdef? If there's a need for multiple libdefs to be maintained for different Flow versions, they can still do that with semver (e.g. version 1 is flow 28-30, version 2 is 30-38, version 3 is 38+), but I think the majority of libdefs don't necessarily need to have granular flow version support like that.

In the general case, a user is (probably) using the latest version of Flow, right? So that user would likely just install the latest version of the libdef and be okay, whereas the special case (users that are on old Flow versions that don't work with the latest libdef version) will have to do a bit more work and find the correct major version to install. I think it's a fair trade-off for the ability to install packages via npm.