Allow single-file analysis mode

[olbrich]

I've been using the codeclimate linter on a fairly large codebase on a mac and have found a couple of issues around the new improved behavior.

1. It takes a long time to get feedback because the codeclimate is re-analyzing my entire codebase when I save a file. (which takes somewhere around 240,000 ms)
2. The full analysis can be very CPU intensive (at least partly because volume mounts on macs aren't very efficient), which can be problematic if I'm running on batteries.

Perhaps a better approach here would be to do a single file analysis on the saved file and then have an option / separate command to do a full analysis.

[cgalvarez]

Hi @olbrich ! First of all, thank you very much for your feedback and insights!

The linter scope must be either (previously) file or (currently) project. I presume this is provided on Atom start, so it shouldn't be feasible changing it on-the-fly after the linter has been registered without an Atom restart.

As an immediate workaround, you could modify your .codeclimate.(json|yml) to drop the engines/plugins that most rely on multi-file analysis, like similar-code or identical-code checks, or even to fine-tune the exclusions (see advanced CodeClimate configuration for more details) to speed the analysis up (if possible).

If it could be done, I think the most useful, straightforward solution would be adding an indicator to the status bar with the CodeClimate icon and the current, selected scope (file or project), with a binded keymap to toggle it.

I'm a bit busy right now, but I'll take a look at this as soon as I can with a proof-of-concept to test if it is feasible. Other solutions/thoughts welcome!

[olbrich]

@cgalvarez thanks for looking into this.

Realistically I would probably use it primarily in the single file mode and only occasionally do the full analysis. Is there a way to import the results of the last run on Codeclimate website? That might be more performant than running it locally in some cases.

Another useful option might be to specify which engines to run (with -e rubocop) as an argument so users can run a subset of engines without having to modify the codeclimate config file.

[cgalvarez]

Is there a way to import the results of the last run on Codeclimate website?

The cli does not seem to support such feature, but I've just discovered that Code Climate has a public API. I suppose it would be feasible to fetch the last cloud analysis and cache it on every opening of new project.

I assume this would imply to track every project file and its content (with some content hash) to detect when a file has been really modified (currently saving a file without changes fires the Code Climate analysis in Atom) to leverage the cloud analysis cache, but this could lead to wrong issues due to some cloud analysis affecting several interrelated files (i.e. duplicated code) that could have been locally modified since then and thus report to wrong locations or even inexistent issues at that time.

Besides that, the package would need to consider working offline (CC cloud API would not be available) to fallback to full local analysis or it could break its functionality.

At my first sight, this approach seems to me a bit overkilling and requiring some hard work to implement that logic.

To me, the two approaches are clear and straightforward:

• File: Run a single file analysis on each save for the modified file.
• Project: Run the full project analysis on any project file save.

To me, the very first proof-of-concept is testing if switching package mode on-the-fly without an Atom restart is feasible.

The cache based on content hash to avoid re-triggering new analyses from non-modified files is a plus that could be done as a separate PR to improve performance.

Another useful option might be to specify which engines to run (with -e rubocop)

I didn't think about that. Certainly it seems a more comfortable way to deal with toggling engines.

[jaredhales]

I have been running into the same issues as @olbrich, we have a large codebase and the change to do project wide linting has made this unusable for me. What do you think about at least having a setting to determine which mode to run in as part of the Atom plugin?

[olbrich]

@cgalvarez have you had a chance to look into this lately?

[olbrich]

@cgalvarez @Arcanemagus is this project abandoned now?

[Arcanemagus]

I've been unable to get a response from the CodeClimate people, and nobody that actually uses this has stepped up to take it over so at the moment it is "looking for a maintainer".

Last I checked CodeClimate still didn't work on Windows so testing this myself is very difficult.