Can we show auto-fix results in the demo?

[platinumazure]

Now that the demo has been rewritten, it would be awesome if we could show auto-fix results! (The motivation for this is to provide a quick way to verify incoming bugs that focus on auto-fix issues.)

It would be awesome if we could show auto-fix results without clobbering the original code, too (or at least allow the user to show fixed/broken code via a toggle maybe?).

Possible tasks (may be inaccurate):

• Ensure source-code-fixer, rule-fixer, etc. are included in the browserify'd ESLint so the web demo can access those modules (might require creating a WebEngine API as noted in other discussions?)
• Ensure fix:true is passed to the linting call so fix info and output are available
• Add control to demo for showing fixed output

[ilyavolodin]

I looked into it while rewriting the demo. As you mentioned, it's not something we can do without changes to the core, since CLIEngine is not browserified (nor should it). I think approach with WebEngine API is incorrect. We would need to add WebEngine API into the core, and that doesn't make much sense to me, since we specifically telling our customers that the only platform that we support is Node.
I think the more correct approach would be to split auto-fix API into two parts, fixing and saving to a file. Saving to a file part should stay in CLIEngine, but fixing should be moved into linter object. I'm still not 100% sure why @nzakas put auto-fixing into CLIEngine.

[nzakas]

Only writing to a file is in CLIEngine. The main functionality is in SourceCodeFixer.

[ilyavolodin]

Ah, you are correct. In that case, we should expose SourceCodeFixer in the linter object (if it's not already exposed. But I don't think it is).

[not-an-aardvark]

The functionality for applying a single round of fixes is in SourceCodeFixer, but the multipass logic is in CLIEngine (here). As far as the demo is concerned, it would be nice to be able to look at multipass autofix results, since the intermediate autofix results aren't really relevant to the user most of the time.

[nzakas]

I don't think we should be tacking things onto linter just to expose them to the demo. Id much rather go the WebEngine route and do this is an organized way.

[gyandeeps]

I will work on this once eslint/eslint#8631 is merged.

[gyandeeps]

WIP - Once 4.1.0 is released then I can update the demo site

I am not a designer so plz feel free to give some suggestions. 😄

[gyandeeps]

@eslint/eslint-team any thoughts on the design ☝️ ?

[ilyavolodin]

Why do we need to show fixed code in separate window? Let's just replace original code with fixed (need to add some sort of button to activate fix mode).

[platinumazure]

I like the idea of seeing good and bad code side by side, personally.

…

On Jun 22, 2017 4:55 PM, "Ilya Volodin" ***@***.***> wrote: Why do we need to show fixed code in separate window? Let's just replace original code with fixed (need to add some sort of button to activate fix mode). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#322 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARWesihV9dDE8sQ1iLlcghbKZUFhOFtks5sGuLggaJpZM4La0w8> .

[gyandeeps]

I like side by side also as I maybe testing some rule and interactively trying things. Otherwise it will be so annoying to see my code vanish as soon as i stop typing. Its easy to see the changes applied (for context sake).

[ilyavolodin]

In that case, current design looks good to me.