0.1.0-0 • Published 7 years ago
@flows/execa v0.1.0-0
@flows
A proof of concept of alternative Flow Library Definitions manager. Strict "work in progress" state, I learn a lot about Flow.
- Library Definitions ("libdefs") are published as standalone packages with independent versions – whenever target dependency got major version bump there should be a major bump of libdefs as well
- Flow version doesn't matter – when it doesn't work with the latest one then it's a bug
- Target dependency version is specified in libdefs
package.json
as peer depehdency flows
CLI modifies[libs]
in.flowconfig
with libdefs dev dependencies found across root package and/or Yarn workspaces instead of copying files into special folder
How to
packages
├── foo/
│ ├── src/
│ │ └── index.js
│ ├── package.json
│ └── readme.md
├── bar/
│ ├── src/
│ │ └── index.js
│ ├── package.json
│ └── readme.md
└── package.json
$ yarn add --dev flows-sync
{
"scripts": {
"postinstall": "flows"
}
}
$ yarn add --dev --ignore-workspace-root-check @flows/one
$ yarn add --dev --cwd packages/foo @flows/two
$ yarn add --dev --cwd packages/bar @flows/three
^ "Libdefs" to choose from are stored in packages/lib/
$ yarn flows
diff --git .flowconfig .flowconfig
+[libs]
+node_modules/@flows/one/src
+node_modules/@flows/two/src
+node_modules/@flows/three/src
^ Ruins comments and newlines between sections, have to write own .flowconfig
parser/serializer
^ flow/issues/5749 + flow/issues/2364 so only one node_modules/@flows
line needs to be included to [libs]
^ flow/issues/153 to get rid of custom (?) .flowconfig
format in favor of JSON/YAML/TOML and/or field in package.json
^ flow-typed/issues/1494?
0.1.0-0
7 years ago