Flow: Use defaults when no .flowconfig present

[mcandre]

Assume some defaults, so that newbies can use flow without fear. They shouldn't see

$ flow
Could not find a .flowconfig in . or any of its parent directories

[gabelevi]

At the very least we need to know the root directory for the project. Technically touch /path/to/root/.flowconfig (which is basically what flow init does) is sufficient for Flow to run and know that the root of the project is at /path/to/root. If settings don't appear in the .flowconfig we assume the defaults.

We could always assume that the current working directory is the project root if we can't find a .flowconfig, but I'm worried that we're going to end up with flow servers watching lots of random directories. Every time you run flow in the wrong directory it will start up a new server. The .flowconfig's do a good job of marking the places where flow servers should be running

[mcandre]

You could look for VCS metadata with vcdetect, though it may be a better idea to simply look up to $HOME, as jshint does.

For code checkers, there's a convention to look up as far as $HOME, then switch to /etc/, then just use whatever defaults should satisfy 80% of your users.

[bcherny]

The strategy should be:

1. Check if there is a .flowconfig in the pwd. If so, use it.
2. Traverse up, checking for .flowconfigs in each dir along the way. If one is found, use it.

See the way NPM does it with .npmrc (NPM also supports global and per-user .npmrc's) - https://github.com/npm/npm/issues/4751

[monolithed]

+1.

[balupton]

Wouldn't the root of the project always be the current working directory... at least for all my use cases it is...

[mcandre]

Wouldn't the root of the project always be the current working directory

The user may have temporarily cd'd to a subdirectory of a larger project controlled by a single config file.

[ELLIOTTCABLE]

So, I have the same concern: This is confusing, as a newbie; and moreso, for small projects, I _really_ don't want to munge up an otherwise-three-file repo with a fourth, versioned, .flowconfig file with four empty INI sections, that never gets modified.

Regarding flow servers: why not print a warning, and then use flow check mode _on the current directory_? That's slower, but a lot less confusing for new users. (This means no ‘zombie flow servers’ for random directories.) If you want Faster Flow, then touch .flowconfig and .gitignore it. This doesn't seem to onerous for new users, while still being less confusing than the current behaviour. (=

[lacker]

If .flowconfig is not found, it could instead look for a package.json.

[tronster]

If it makes any difference, I just came here from the top hit of Googling "Could not find a .flowconfig". Using flow just as a prereq for a Sublime 3 javascript plug-in so it would have been more convenient if flow has just auto-created an empty .flowconfig rather than require me to Google the problem to learn I needed to create an empty file.

If automatically creating an empty .flowconfig file breaks in certain environments then at the very least please consider mentioning the solution of manually creating an empty .flowconfig in the error message itself.

[victorb]

Would the Flow team be open to merge a PR implementing the strategy mentioned in https://github.com/facebook/flow/issues/389#issuecomment-96433415 ?

[ClintEsteMadera]

Similarly to how other tools like Babel, ESLint, Jest and Prettier do (to name a few), I would like .flowconfig to be subject to be shared across projects. So, I would like the ability to either have a "flow" key in my package.json pointing to the NPM package that exports such config file:

{
    "flow": "@my-company/common-flow-config",
}

or, similarly, something like:

{
  "flow": {
    "extends": "@my-company/common-flow-config"
  },
}

Does this make any sense?