Agreed 100% here, encoding team rules around stuff like this in eslint configurations frees devs to spend their code review time focusing on reviewing logic and design rather than nitpicking style issues.
Definitely agree with the use of Linters. Been using ESLint for a project with other devs. Unfortunately, logs still make it into production :( Definitely could benefit from a build process that would clean that up for us. But that only fixes code and not the source ;)
If this continues to be an issue, it may be worth your time to set up required status checks on your repository using the Status API and webhooks. You can use these tools to automatically reject pull requests that contain code changes that fail ESLint validation.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
console.log
's happen and you don't always catch them. Not even with regular expressions.Do you know what do? Linters.
As a rule of the thumb, I always say to my collaborators: "Never commit
console.log
statements, so that's why we're enforcingno-console
in ESLint."Agreed 100% here, encoding team rules around stuff like this in eslint configurations frees devs to spend their code review time focusing on reviewing logic and design rather than nitpicking style issues.
Definitely agree with the use of Linters. Been using ESLint for a project with other devs. Unfortunately, logs still make it into production :( Definitely could benefit from a build process that would clean that up for us. But that only fixes code and not the source ;)
If this continues to be an issue, it may be worth your time to set up required status checks on your repository using the Status API and webhooks. You can use these tools to automatically reject pull requests that contain code changes that fail ESLint validation.