Support external ESLint configs

[caiges]

For my organization's projects and my own I use an external npm package that houses my eslint config. It would be nice to support this workflow as eslint configs change slowly so sharing via npm package or similar means is a fairly common practice. This workflow is described in ESLint's shareable configs documentation.

[cilindrox]

Probably related to #75

[dblandin]

Hi @caiges,

We don't currently support ESLint plugins or shared configs via NPM due to security concerns. We've made a few exceptions for popular plugins that we now include within the engine. What we recommend for now is to keep a shared config within the repo and periodically update it.

Here's a good example:

https://github.com/sagiegurari/simple-oracledb/blob/master/.codeclimate.yml
https://github.com/sagiegurari/simple-oracledb/blob/master/.eslintrc.js
https://github.com/sagiegurari/simple-oracledb/blob/master/project/config/eslintrc-common.json

Here at Code Climate we have a separate repo which holds our shared configs.

Sorry I don't have a better approach to suggest but that's what we can support today.

Thanks!

[caiges]

Thanks for the info @dblandin. Could you elaborate on the security issue if you can? I'd like to help address the issue if it's something ESLint is doing specifically.

[dblandin]

@caiges,

Unlike many popular CI systems, our build infrastructure isn't yet designed to execute customer code. It was designed to run engines statically against source code. Before we allow arbitrary execution of customer code (including NPM packages or RubyGems), we have some work to do to ensure that our systems and customer data remain secure. Unfortunately, this isn't an issue specific to ESLint. It's a shared concern across our platform.

Another workaround is to use our CLI, which you can run locally and in your own CI environment. You may be able to run npm install and codeclimate analyze to get things to work. Of course you'd miss out on the value codeclimate.com provides.

[caiges]

@dblandin Wow, great response - thank you. This isn't a showstopper for us and it's nice to know you're thinking about the issue.

[dblandin]

@caiges My pleasure! Thanks for the support!

[mansona]

Right, so this one is a showstopper for us 😭 Has there been any movement to support third-party shared configs yet? Essentially I want what codeclimate.com is providing i.e. showing improvements on a branch/PR level

I have noticed from #75 that you support the airbnb style so a workaround for us would be to be able to configure a custom "extends" in the .codeclimate.yml file because our custom shared config is quite close to theirs. This would allow us to use the .eslintrc.json file locally with our local development and "put up with" a few false positives on code climate.

I hope all this makes sense 😂

[maxkoryukov]

The same case: we have our own ESLint config in a separate NPM package, it is inherited from one of the common-well-known configs, but we want to use other syntax guidelines..

And now we are unable to use Codeclimate , because custom configs (enclosed in packages) are not supported...

[pbrisbin]

Hey folks. I just wanted to let you know that I created a sticky issue at qltysh/qlty#480 to document this limitation, some of the reasoning behind it, and provide an avenue for any updates from our side. I'm going to go ahead and close this issue here, because the limitation is broader than any one engine.

@mansona the extends idea sounds promising, but I'm not sure I completely follow. Would you be able to open a new feature request that outlines it in more detail? A PR that attempts to implement it would be ideal.

[mansona]

I'll split my reply into two comments:

To explain my "extends" idea: Essentially I have 3 tiers of rules being applied to my eslint now, the vast majority coming from Airbnb's external config. Next, I have a .eslintrc.json file that makes specific changes that I need so for my current projects:

{
    "env": {
      "node": true
    },
    "extends": "airbnb",
    "rules" : {
      "new-cap": [2 , { "capIsNewExceptions": ["Q", "ObjectId"] }],
      "no-underscore-dangle": [2, { "allow": ["_id"] }]
    }
}

The idea of having my own external config was so that I didn't have to maintain this ^^ exception based eslint.json on every repo and change all our repos once we need to change something.

The last tier of the solution is to add this to our .codeclimate.yml file:

    enabled: true
    channel: eslint-2
    checks:
      import/no-unresolved:
        enabled: false 

This means that the import/no-unresolved rule works locally for us but doesn't create issues on code climate.

This issue has already had a chilling effect on our development. We want to continue with our own slightly custom coding style, but we have had to remove a lot of the customisations we were using because having Code Climate is more valuable to us than having our style followed. Just to be clear this is not a good thing.

If you are not going to allow us to use the standard method of including custom configs, I would recommend that you do something on the backend like allowing us to define our own rules in our accounts that can apply to all our applications. This way we could have our local @stonecircle ruleset, and you could have a server-side definition of rules that contains and all would be right with the world 🎉

[mansona]

@pbrisbin I am commenting here instead of qltysh/qlty#480 because that issue is locked, are you planning to open that up for further discussion?

I know that you have a major security issue to contend with here (and I'm not a security professional) but I don't understand why this isn't a solved problem already? Travis-ci already allows you to install any npm package your want, surely we can re-use some of their solutions for this?