Check out a free preview of the full Code Transformation and Linting with ASTs course:
The "Challenge 5: Applying Fixes" Lesson is part of the full, Code Transformation and Linting with ASTs course featured in this preview video. Here's what you'd learn in this lesson:

In this challenge, students learn how to incorporate the ability to fix bad code automatically. - http://eslint.org/docs/developer-guide/working-with-rules#applying-fixes

Get Unlimited Access Now

Transcript from the "Challenge 5: Applying Fixes" Lesson

[00:00:00]
>> Kent C. Dodds: So go ahead and run, npm start exercise.eslint., what are we on, 3, 4? 4.
>> Kent C. Dodds: Okay so with this one, the test changed slightly. Now this invalid case that we just solved for is, or not all of the invalid cases, this invalid function that we had, now it's accepting a second argument called output.

[00:00:41] And if that output is present then we'll add that to our invalid test. So part of this tester API, just to show it less abstracted, is code like the bad code. The errors that you expect to see, and properties from those errors, and the output. So ESLint has the capability of automatically fixing code.

[00:01:11] And you as a plug-in author are responsible for writing the code to automatically fix the code, so doing things like adding or removing semicolons or spacing. Adding a block, like that if statement that we were doing earier, you could add a block around that, and so for us, we don't want people to use console because we have problems with console in our app.

[00:01:36] Instead, we want people to use this global logger that we have available. So because it's nice to have the lint rule so that we make sure nobody pushes stuff that is using console. But it's even better if we can automatically fix it. And especially if it's something kind of simple that we know we're not gonna break anything, then may as well just automatically fix it, so that is your task.

[00:02:01] A couple of things.
>> Kent C. Dodds: A couple of things that you need to make sure or that I need to make sure you know about doing this. So first off, on this meta object here, You have to provide a property, called fixable. And so I'll just type that here fixable.

[00:02:23] And you can either put white space or code. And I'm not sure what impact that actually has on anything, but we're gonna be fixing code, so just put code in there.
>> Kent C. Dodds: And then from here, let's see, no, no, no. Yeah, so from here, you, on your contacts.report, you provide a fix function that accepts a fixer parameter, and this fixer has some methods on it to help you fix the code.

[00:03:04]
>> Kent C. Dodds: And that is documented in a place that I will show you, fixer, Applying Fixes.
>> Kent C. Dodds: And here are all the fixer functions you can call. I'll just give you a tip, the one you're gonna call is replace text.
>> Kent C. Dodds: So here we'll say fixer.replaceText. You'll pass in the note that you want to replace and then a string for what you want to replace it with.

[00:03:33] So the node and the string.
>> Kent C. Dodds: Another tip is this report function, or the this context report. We're using it twice and using it in a pretty similar way. And our fixer is actually going to be identical. And so you could refactor this a couple different ways. I see in lots of ESLint plugins, people will create a report function that accepts parameters, because often the report looks exactly the same.

[00:04:07] And yeah, so that's what my solution does. But you could also just create a fixer function up here and just pass it along to both of those report calls. However you wanna do that.
>> Kent C. Dodds: One last thing that is kinda sad. I'm gonna have to make you all do this.

[00:04:25] You don't have to if you don't want to but, well actually two things, first off AST explorer doesn't support the fixture function. So it's not gonna run your fixture function you won't see that which is kinda sad. Pull requests welcome I'm sure. But ESLint, the test runner, if your code is different, here, actually we'll just experience this right now.

[00:04:51] Let me run npm start.
>> Kent C. Dodds: So we're getting a bunch of errors because our fixed code, actually, we're not actually fixing anything. So the code looks exactly the same after it runs through our fixer. And so we're getting this error, output is incorrect, but we're not seeing what the output looks like.

[00:05:13] That's a real bummer. And ESLint is using Node's assert module, and the testing framework we're using is Jest. And until the next version, just for this workshop I made a pull request to Jest to make it support the assert module better. And the next version is going to have much nicer output, but it didn't quite get shipped.

[00:05:36] So I will show you how to hack ESLint so that it will show you what the code looks like, so that as you're developing things it's a little bit better. Actually, I kinda documented this in the other directory, /copy.md. So you'll go to this file, go to line 532, and paste this code, and then you'll get better output.

[00:06:07] So I'll do that really quick, and then you can just look at that copy.md. And we'll find ESLint.
>> Kent C. Dodds: And it's in lib > testers > rule-tester. It's line 523.
>> Kent C. Dodds: Hold on, is that right, 532. There we go. So it looks like this where it has the fixed results and it does this assert.equal, right here.

[00:06:38] So right above that assert .equal, you'll paste that code that I have in the copy. And then if we rerun the test then we're gonna see much more much more useful output. Which again, the next version of Jest will show this in an even better way. So sorry that you have to do that for now.

[00:07:02] And next time you install the modules all this will be blown away, which is really sad.