Add support for common IBM/StrongLoop configs

[rmg]

IBM's StrongLoop, LoopBack, and API Connect projects use these shared
configs (originally only eslint-config-strongloop) for their various
open source projects under http://github.com/strongloop

[rmg]

Oh, and 👍 x 💯 for this repo's CONTRIBUTING.md - It was great to be able to test this locally instead of waiting for it to land and get deployed and then poke my repos to verify the change.

[dblandin]

Hi @rmg,

Thanks for the PR! We usually don't pull in shared configurations for specific organizations unless they're widely used by the community at large.

Would our prepare step meet your needs?
https://docs.codeclimate.com/v1.0/docs/configuring-the-prepare-step

For example, you could use the following .codeclimate.yml configuration to pull down your shared ESLint configuration (tagged v.8.0.0):

prepare:
  fetch:
  - "https://github.com/strongloop/eslint-config-loopback/blob/v8.0.0/eslint.json"

[rmg]

We usually don't pull in shared configurations for specific organizations unless they're widely used by the community at large.

That's a perfectly reasonable stance. Is there some metric that is used for this? Since devDependencies aren't reflected as the dependents for upstream modules on npmjs.com it's a bit hard to count actual usage. This would tell me if/when I should check back.

Would our prepare step meet your needs?

In a pinch, yes, but it's not really something I want to be doing across 250+ repos.

Even if this PR was accepted it wouldn't actually solve my problem; it just pushes it toward being version mismatches over time instead of just an unsupported shared config. Of course, that's the same problem all the existing shared configs also have whenever they see a semver-major update here before projects switch to the latest versions (whether they want to or not).

This is a problem in general with these tools (Code Climate, Codacy, SonarQube, etc..) pre-loading eslint plugins and configs in a static manner. Unfortunately there's no easy/obvious solution since installing dependencies each time the linter runs is both expensive and introduces a potential attack vector on the infrastructure.

[dblandin]

That's a perfectly reasonable stance. Is there some metric that is used for this? Since devDependencies aren't reflected as the dependents for upstream modules on npmjs.com it's a bit hard to count actual usage. This would tell me if/when I should check back.

It's a bit off the cuff but I usually check download counts on npm and stargazers/followers/activity on GitHub.

In a pinch, yes, but it's not really something I want to be doing across 250+ repos.

Ahh, yep, I wouldn't want to do that either. Are all of your repos under the same Code Climate organization? I wonder if configuring the prepare step at the organization level would be more practical for that number of repos.

This is a problem in general with these tools (Code Climate, Codacy, SonarQube, etc..) pre-loading eslint plugins and configs in a static manner. Unfortunately there's no easy/obvious solution since installing dependencies each time the linter runs is both expensive and introduces a potential attack vector on the infrastructure.

Right. Definitely a tricky problem. Here's a bit more context about our own security concerns as it relates to installing and executing arbitrary plugins: qltysh/qlty#480

We hope to provide a better solution in the future.

[dblandin]

Hey @rmg,

After conferring with some colleagues, we've decided to merge this PR due to the number of repositories you're setting up. We hope to offer an easier way to set up external configurations for a large number of repositories in the future, but for now, bundling them into the engine will do.

If you have any feedback as you continue to onboard repos, please let us know either here or via support at https://codeclimate.com/help.

Thanks!

[rmg]

I wonder if an external tool/service would help. Something that inspects a given package.json and .eslintrc and then spits back out an inflated/flattened .eslintrc that just has all the externally defined rules inlined. It wouldn't help with custom plugins, but it would at least handle the shared config case. 🤔