jtfairbank
commented
8 years ago Oh yeah, super bonus points if you can also include an option to automatically ignore text in comments. I haven't thought about this as much, but I feel like the same techniques can be applied.
Use case: clearly the comment here should not provide a match, even if I want to check the grunt file for other console.logs.
/* Plugin: Search
* ------------------------------------------------------
* [Docs](https://www.npmjs.com/package/grunt-search)
*
* Search for text in files and log it or fail the task.
*/
search: {
// search for console.log statements
console: {
...
}
}
benkeen
Hi benkeen, great work here. I just spent the last hour adding this to a bunch of our repos, can't wait to find all the bad code with it.
The Problem
My biggest issue is that I have to do some pretty icky regexes to determine if a search match is ok or not. A great example is that in our js code, 90% of the time it is a mistake to include a
console.logstatement. That usually indicates someone forgot to remove some debug code, or someone got lazy and isn't properly reporting error conditions.However there are valid use cases for
console.log, such as in the error reporting system itself (one reporter is a console logger).Current Workaround:
Suggested Improvement
Many developers in the js community are already familiar with jshint. They have great support for ignoring all or some errors for single or multiple lines: JSHint Docs - search for ignore.
I propose that
grunt-searchadds a similar ignore comment system. Based on the regex above, it could look something like this:// grunt-search[:console] ignore:lineWhere the
grunt-searchterm provides an anchor to search for, the optional:consolespecifies a specific grunt task to ignore (excluding it ignores the line for all tasks), and the ignore directive indicates the scope of what to ignore.Multi-line ignores can be added fairly easily as well:
// grunt-search[:console] ignore:start// grunt-search[:console] ignore:endI feel like this strikes the right balance between tool scope and flexibility. It doesn't require a complicated generic ignore system, but the users can still mark specific sections of code to not check, and specify specific (or all) tasks to ignore.
Implementation Notes
The place to do this would be at the start of the main loop which iterates through each line.
Specify a regex for the ignore:
grunt-search[:(\S)] ignore:line(and start / end). At the start of the loop, run the regex for a match. If there is one, check the regex's group for a specific grunt command, and if the command doesn't match the one proceed with the search.If a line ignore is found, just
continuewith the loop.If a multi-line ignore is found,
continuewith the loop until the multi-line end ignore is found.If a multi-line end ignore is found without a preceding multi-line start ignore, throw a warning (but probably don't fail the task).
If there are "nested" multi-line ignores, throw an error. Or implement a counter which increments on multi-line starts and decrements on multi-line ends, and only resumes searching when it reaches 0. Or just wait until the the first multi-line end is reached, which closes any / all preceding starts. As long as this case is documented clearly, we'll all be fine.
Might also want to throw warnings if there are malformed comments, such as:
// grunt-search// grunt-search[:console]// grunt-search[:console] [not ignore]// grunt-search[:console] ignore// grunt-search[:console] ignore:[not line / start / end]Other Possible Workarounds
Excluding specific files is problematic because nothing in the file will be checked (and most of the lines should be), and we'd have to update the file listings quite often- basically anytime a file becomes an exception to the search term.
Closing Thoughts
I'm super busy through January but can try to get a PR out in February. If you want to implement this, I'd also be happy to buy you a beer via Paypal / Venmo / Patreon / Grattipay.
Cheers, jtfairbank