Automate generation of eslint globals & flow definitions
This may not be deemed high priority, but it feels like there is unnecessary friction in managing both the eslint globals and flow definitions. I have a few questions that I believe would need to be answered in order to move forward:

### `skpm/eslint-config-sketch` vs `@jongold/eslint-config-sketch`

What are the advantages of using one over the other? Was work just being done in parallel or are there intentional differences between the two? 

I do notice that `@jongold/eslint-config-sketch` includes a few [non-sketch globals](https://github.com/jongold/eslint-config-sketch/blob/master/nonSketchGlobals.js).

What would need to be done in order to converge on a single lib?

### Non-sketch globals: `react-sketchapp` vs `@jongold/eslint-config-sketch`

Is there any rule of thumb of when to add globals directly in `react-sketchapp/.eslintrc` vs when to add rules within `@jongold/eslint-config-sketch`?

I think it would make more sense to manage all of these "non-sketch" globals in a single location.

### Can we automate creation of non-sketch globals?

It looks like all additional globals are coming from MacOS libs (with the exception of `context` and `log` which I believe are skpm specific?). Can we get these values automatically by utilizing `classdump` (similar to what is done in [sketch-headers](https://github.com/skpm/sketch-headers))?

### Can we automate creation of flow definitions?

Similar to the automation techniques used for generating eslint-config... can we dynamically create flow definitions from [sketch-headers](https://github.com/skpm/sketch-headers)?

---

@mathieudutour @jongold