Support for flow syntax extensions.

[Gozala]

Is there way to support flow syntax extensions for projects that want to use that ?

[jprichardson]

You can, just use the babel-eslint parser for Standard and add the necessary plugins for Babel. This is what I use: https://github.com/codemix/babel-plugin-typecheck.

[Gozala]

So I run into following issue gajus/eslint-plugin-flowtype#72 when using standard with babel-eslint and eslint-plugin-flowtype

[Gozala]

Also babel/babel-eslint#293 seems relevant here.

[feross]

@Gozala Are you specifying the flowtype plugin in your package.json config for standard like this?

{
  "standard": {
    "plugins": ["flowtype"]
  }
}

Setting a custom parser and plugins are the only ways you can try to solve this issue with standard. We intentionally don't support enabling/disabling rules.

If you require enabling extra rules from the flowtype plugin and/or disabling rules in standard to get your code to pass, then I would suggest using eslint directly in your project. You can extend from eslint-config-standard and just change the few rules you need to change.

[Gozala]

@feross Yeap that is pretty much what I use:

{
  "standard": {
    "parser": "babel-eslint",
    "plugins": [
      "flowtype"
    ]
}

The problem as described in babel/babel-eslint#293 is that babel-eslint does not seem to have a way of informing eslint that type import is different from value import & there for eslint will report duplicate imports.

If you require enabling extra rules from the flowtype plugin and/or disabling rules in standard to get your code to pass, then I would suggest using eslint directly in your project. You can extend from eslint-config-standard and just change the few rules you need to change.

That is what I end up doing for now, but I would much rather not do that. Maybe standard could avoid this issue by using import/no-duplicates instead of stock no-duplicates ?

[feross]

The import plugin actually looks really well done. Adding another eslint plugin is not ideal for running time, but if there are other rules in there that would make standard catch more errors, I'm open to considering it. (As an added bonus, flow type annotations would work again.)

[Gozala]

but if there are other rules in there that would make standard catch more errors, I'm open to considering it.

@feross I believe it primary selling point is:

prevent issues with misspelling of file paths and import names

Also should I open new issue regarding duplicate imports issue caused by import type ?

[Gozala]

Setting a custom parser and plugins are the only ways you can try to solve this issue with standard. We intentionally don't support enabling/disabling rules.

Would not it be reasonably to allow configuring those plugins ? It would not solve the duplicate imports issue I'm afraid, but I did also notice that I'm unable to configure flowtype plugin which can catches bunch of errors otherwise.

[Gozala]

Created a separate issue in regards to no-duplicate-imports casted by import type:
#599

[feross]

Would not it be reasonably to allow configuring those plugins ? It would not solve the duplicate imports issue I'm afraid, but I did also notice that I'm unable to configure flowtype plugin which can catches bunch of errors otherwise.

This is a slippery slope. When you see standard is being used on a repo, we want that to mean something. If you can configure rules, then it means less because contributors will need to see exactly which rules you have added before jumping in. This was discussed extensively in #399 and it was decided not to support this.

If you really want a flow-type variant of standard, I suggest writing a fork like standard-flow. You can see https://github.com/feross/standard-react or https://github.com/Flet/semistandard for an example of how to write a fork of standard that extends the existing rules and modifies a few of them.

[Gozala]

If you really want a flow-type variant of standard, I suggest writing a fork like standard-flow. You can see https://github.com/feross/standard-react or https://github.com/Flet/semistandard for an example of how to write a fork of standard that extends the existing rules and modifies a few of them.

Thanks. I have followed this advice and created https://github.com/Gozala/standard-flow and https://github.com/Gozala/eslint-config-standard-flow to add flow support and lint type annotations with the same rules as rest of the code.

[ArmorDarks]

I think that forcing forks is terrible idea, because they almost always lags behind main library and ends up unmaintained.