Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add flow compatibility #20

Merged
merged 5 commits into from
Jan 25, 2018
Merged
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions browser/index.js
Original file line number Diff line number Diff line change
Expand Up @@ -16,13 +16,13 @@ module.exports = {
globals: {
// TODO: We should not globalize this - we should explicitly import our CDN-sourced dependencies.
Backbone: true,

/**
* We need to globalize `analytics` because of the way Segment's library loads. It redefines
* `window.analytics` after loading, which, when `analytics` is not globalized, causes issues
* because the `analytics` rollup catches may not be the `window.analytics` we want.
*/
analytics: true
analytics: true
},
rules: {
'react/jsx-wrap-multilines': 2
Expand Down
2 changes: 1 addition & 1 deletion index.js
Original file line number Diff line number Diff line change
Expand Up @@ -38,7 +38,7 @@ module.exports = {
}
}
}],
// Console logs should be mostly nonexistent, and places like app.js should just have a
// Console logs should be mostly nonexistent, and places like app.js should just have a
// /* eslint-disable no-console */
// comment at the top.
'no-console': ['error'],
Expand Down
39 changes: 39 additions & 0 deletions node/flow.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
module.exports = {
parser: 'babel-eslint',
extends: 'mixmax/node',
plugins: [
// Allows correct parsing of flow annotated files.
'flowtype'
],
rules: {
'space-infix-ops': 0,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this go in our base config? same Q on no-duplicate-imports

'no-duplicate-imports': 0,
// Makes flow `type` definitions defines
'flowtype/define-flow-type': 1,
// Do not allow spaces before type declarations, i.e. let a: number, not let a : number
'flowtype/space-before-type-colon': [
1,
'never'
],
// Marks flow type declarations as used to prevent no-unused-vars for types
'flowtype/use-flow-type': 1,
// Enforces camelcase for type definitions
'flowtype/type-id-match': [
2,
'^([A-Z]+[a-z0-9A-Z]*)$'
]
},
settings: {
// Only use the flow linter for files with `@flow`
flowtype: {
onlyFilesWithFlowAnnotation: true
}
},
parserOptions: {
// Required to support import/export syntax when using types
sourceType: 'module',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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" ]

ecmaFeatures: {
experimentalObjectRestSpread: true,
Copy link
Contributor

@spencer-brown spencer-brown Jan 25, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

},
}
};
7 changes: 4 additions & 3 deletions package.json
Original file line number Diff line number Diff line change
Expand Up @@ -30,14 +30,15 @@
},
"homepage": "https://github.com/mixmaxhq/eslint-config-mixmax#readme",
"optionalDependencies": {
"babel-eslint": "^7.2.3",
"babel-eslint": "^8.2.1",
"eslint-plugin-flowtype": "^2.41.0",
"eslint-plugin-react": "^7.1.0"
},
"peerDependencies": {
"eslint": ">= 3"
"eslint": ">=4.14.0"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

},
"devDependencies": {
"eslint": ">=3",
"eslint": ">=4.14.0",
"eslint-config-mixmax": "^0.7.0",
"pre-commit": "^1.2.2"
},
Expand Down
Loading