Add flow compatibility #20
Conversation
| "eslint-plugin-react": "^7.1.0" | ||
| }, | ||
| "peerDependencies": { | ||
| "eslint": ">= 3" | ||
| "eslint": ">=4.14.0" |
There was a problem hiding this comment.
can you please update the README with updated dependency installation instructions? (describing the optional flowtype dependency and updating the version of eslint that needs to be installed)
separately, it looks like the README is outdated in other ways - mentioning forthcoming configs that have already been added, not including the jest config, requiring node >=7.6.0, and describing the project as being at v0.1 - i'm happy to clean these up after you merge this or feel free if you want to knock them out while you're in here.
node/flow.js
Outdated
| 'flowtype' | ||
| ], | ||
| rules: { | ||
| 'space-infix-ops': 0, |
There was a problem hiding this comment.
should this go in our base config? same Q on no-duplicate-imports
node/flow.js
Outdated
| }, | ||
| parserOptions: { | ||
| // Required to support import/export syntax when using types | ||
| sourceType: 'module', |
There was a problem hiding this comment.
what if we want to use this server-side with script-type sourceType?
i'm wondering if we want a base flow config that could be mixed with other configs to make eg flow-node and flow-browser.
There was a problem hiding this comment.
To the first point, this works with server-side code just fine as far as I can tell (https://github.com/mixmaxhq/event-logging/pull/1 this correctly enforces rules using this config). On the other point, we could not extend mixmax/node here and instead rely on the client to extend it like "extends": [ "mixmax/node", "mixmax/flow" ]
node/flow.js
Outdated
| // Required to support import/export syntax when using types | ||
| sourceType: 'module', | ||
| ecmaFeatures: { | ||
| experimentalObjectRestSpread: true, |
There was a problem hiding this comment.
what do you think about breaking out a new config to be used by transpiled, node-run code and extending that config here? here and in my previous comment, just trying to think about how we can best keep these configs DRY - we might want several experimental features in multiple locations, but won't want to copy/paste those everywhere (instead, we could extend those configs where desired).
here, maybe we want to combine two different configs like flow and node-es6 to create the final product you'd use in a flow-using, transpiled, server-side shared module.
| @@ -0,0 +1,7 @@ | |||
| module.exports = { | |||
|
thanks! excited about this new pattern :). |
I updated the
eslintdependency to support correctly parsing flow annotated files, and also had to upgrade the minimum supportedbabel-eslintversion due to an issue when parsing flow type definitions (issue here).This will be a major version change since it requires 4.X, but shouldn't introduce problems based on the migration guide.