## Usage

Install using `npm i flowgen --save`

```js
import { compiler } from 'flowgen';

// To compile a d.ts file
const flowdef = compiler.compileDefinitionFile(filename);

// To compile a string
const flowdef = compiler.compileDefinitionString(str);

// To compile a typescript test file to JavaScript
// esTarget = ES5/ES6 etc
const testCase = compiler.compileTest(path, esTarget)
```

*Recommended second step:*

```js
import { beautify } from 'flowgen';

// Make the definition human readable
const readableDef = beautify(generatedFlowdef);
```

### CLI

Standard usage (will produce `export.flow.js`):
```
npm i -g flowgen
flowgen lodash.d.ts
```

### Options
```
-o / --output-file [outputFile]: Specifies the filename of the exported file, defaults to export.flow.js
```

### Flags for specific cases
```
--flow-typed-format: Format output so it fits in the flow-typed repo
--compile-tests: Compile any sibling -tests.ts files found
--no-inexact: Do not mark object types as inexact (using `...`)
--no-module-exports: Convert `export = Type` only to default export, instead of `declare module.exports: Type`
--interface-records: Convert TypeScript interfaces to Exact Objects
--no-jsdoc: Ignore TypeScript JSDoc
--add-flow-header: Add `// @flow` to generated files. Should be used for libs.
```

## The difficult parts

### Namespaces
Namespaces have been a big headache. What it does right now is that it splits any namespace out into prefixed global scope declarations instead. It works OK, but its not pretty and there's some drawbacks to it.

### External library imports
Definitions in TS and flow are often quite different, and imported types from other libraries don't usually have
a one-to-one mapping. Common cases are `React.ReactElement`, `React.CSSProps`etc.
This might require manual processing, or we add a set of hardcoded mutations that handle common cases.

### Odd TS conventions
[Lodash](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/9fb1696ad55c0ac54bbf6e477f21b52536211a1e/types/lodash/index.d.ts) has been one of the reference libraries i've worked with when creating the
converter. The definition is mostly just a series of interfaces with the same name being re-declared over and over again for each function, which doesn't translate to flow at all. There's multiple ways of solving this but I don't have a great solution for it in place yet.

### Sample of finding all typescript definition files and generate flow file with shell script
If your typescript definition files are built in `lib` add below shell script and run it.

```sh
for i in $(find lib -type f -name "*.d.ts");
do sh -c "flowgen $i -o ${i%.*.*}.js.flow";
done;
```

So if you have definition files in different dir, you can rename `lib` and run the script.

Here’s an example of the above as an npm script in `package.json` that excludes any typescript definition files found inside `node_modules`:
```json
"scripts": {
"build:flowtypes": "find . -type f -not -path './node_modules/*' -name '*.d.ts' -exec sh -c 'yarn flowgen --add-flow-header $1 -o ${1%.*.*}.js.flow' _ '{}' \\;"
}
```

You can then have a `build` script that generates flow types along the lines of `tsc --build && npm run build:flowtypes`.

## Contributing

All help is appreciated. Please [tweet at me](https://twitter.com/joarwilk) if you want some help getting started, or just want to discuss ideas on how to solve the trickier parts.

## Distribution