Thanks! I like your work on it. I have several ideas on how to generally improve the CSP development that I want to implement, and needed a good infrastructure for doing it:
- CSP optimizations, like removing redundant fields (like a minifier)
- CSP parsing
- CSP security warnings or rating (like for unsafe eval)
- CSP Presets, might be general presets, or extendable presets for various tools, like Google Analytics for example
- CSP deprecations and level supports
Yep, truly avoiding false positives and capturing all todos you would need to really parse the source code (perhaps creating an AST or lexical parsing).
Even if you build that tool (which handles many languages) - it has an extra headache cost with the parsing time, which might be really slow for large projects.
I actually started Leasot with Javascript AST checking which never misses TODOS but is very hard to extend to other languages, as well as parsing speed was a magnitude slower.
Just out of interest, how often do you find yourself using "TODO" as a variable name or elsewhere in your code?
This isn't a dig, it's just something I've genuinely never stumbled across in 2 decades of programming so wondered if there's a culture out there I've missed.
Watson looks really nice... Could definitely learn from it.
In github issues you mean exporting a TODO to a github issue? If so, I don't think that belongs in Leasot, but rather an external tool for creating/manipulating Github issues (And I'm sure that kind of tool exists).
;) I'm in no way offended. I guess kazinator is spending his time much better than me.
But anyway, if anyone is more comfortable using CLI (or any IDE that provides this) with grep/ack/ag/pt and that solves parsing todos for him, that's great.
I would only use Leasot if you need easy integration with other tools (think JSONs/XML), want to trim down false positives (such as variable names, strings etc...).
There are probably other use cases, but overall, if cli regex works great for you, stick with it.
Regarding if Leasot is pointless or not, well everyone is entitled to their own opinion (kazinator). In the greater sense I guess the world needs more todo doers than todo parsers ;)
This is a great solution. I would only use Leasot if you need to weed out some false positives (variable names, strings etc...) and perhaps want to output in a special format (JSON, XML, markdown...) for another tool (Think jenkins CI for example).
If CLI regex matching (grep, ag, git grep, pt, ack...) works for you, I would stick with it ;)
Well you can see my comment above, but overall ag|awk|pt will be much faster (but might be less accurate).
Leasot tries to weed out some false positive (by creating better comment for file type specific comment regexes).
Also provides several reporters (JSON, XML, Markdown...) if you want to integrate with other tools (jenkins, travis etc...)
Leasot is written in Node.js.
Regarding pretty output - that could definitely be argued, but Leasot also allows for different reporters, say you want the output in JSON/XML for an external tool. That is extendable, whereas grep over regex in CLI is fast & powerful but not as flexible
Ah yes, my mistake. Though being written in Javascript makes it even worse for requiring dependencies as at least Python ships with most distros default install.
> Regarding pretty output - that could definitely be argued, but Leasot also allows for different reporters, say you want the output in JSON/XML for an external tool. That is extendable, whereas grep over regex in CLI is fast & powerful but not as flexible
I'd already addressed that point. UNIX pipes allow you to extend grep using any language (including Javascript / node.js) you want. Leasot if only extendible if you already know Javascript and node.js. Plus there are plenty of CLI tools available that can read list input from STDIN and spit out JSON or XML - so you don't even need to learn how to program to convert data files.
I've lost count of the number of times I've seen people write multi-functional programs to solve problems that would have been quicker (both in development time, and execution) to pipe a couple of existing programs together. Heck, I've even fallen into this trap myself before.
Thanks for the comments. Regarding simple `ag` or `grep` usages:
Yeah, that will definitely be faster (as with git grep). The problem arises when you have false positives due to either strings, variable names or other things (perhaps template or pattern matches). Then you will need extremely good regex (which leasot implements) or be really good with filtering the results.
Now what happens when you want the output in different formats?
I had a person contacting me for exporting as xml since he wants to plug it in for a CI (jenkins).
What if you want a JSON for your own tool?
Leasot is far from the perfect solution to TODOs, but if your use case requires anything other than simple regex, you will run into the same issues that Leasot tries to solve.
As far as speed, in my work project, parsing 552 javascript files takes around 0.2s on my mac. Some of these files being really big.
Outputting the data in your own format is actually remarkably simple from the command line - you could build up a complete JSON document by piping the input through `jq`. XML might be a bit harder, but with a bit of find and replace across a template (or by using xmllint), you can create pretty much any document you'd like.
In short, a cool tool, which I hope you had fun creating to fill your needs, but it's not something I could personally justify using at the moment. My lint tools (for Python) and `godoc` already alert me to "XXX" and "TODO" comments, letting me see them as part of my normal programming flow.
I wouldn't expend too much effort trying to convince others of it's utility - you'll get frustrated. Instead, let the tool's utility speak for itself (if its useful to you, it will also be useful to someone else), and move on and create more useful tools.
This could actually be implemented, but it was more work with the regex so I skipped it for now, seeing that most TODOs are at the beginning of the line.
Also, you run into problems with strings which might be a false positive
