The first issue I faced was understanding the code. It took a sweet amount of time to figure out the kind of objects, things certain functions were receiving and what they were doing with them. The code did have some unit tests, but the coverage was poor. So I had to guess, make changes and test the code at many places.
Source: It is becoming difficult for me to be productive in Python.
It's true. It turns out you can, in fact, add C-style for loops into Python. The way to get there however, was long and painful all the way to the end.
Regardless, I've learned many things (some of which I hope nobody ever uses in production), and I'm here to share with you all the gruesome details. I hope you find it helpful (or at the very least, entertaining).
Source: How I added C-style for-loops to Python, an article by Tushar Sadhwani.
Overall eslint is so flexible, that you can even swap out the parser for a completely different one. That's not a rare scenario either as with the rise of JSX and TypeScript that is frequently done. Enriched by a healthy ecosystem of plugins and presets, there is probably a rule for every use case out there and if there isn't, the excellent documentation guides you on how to create your own rules. That's one thing I want to highlight here as it's a project that has stood the test of time.
But this also poses a problem for performance profiling as due to the vastness of the configuration flexibility two projects can have a widely different experience when it comes to linting performance. We need to start somewhere though, so I figured what better way to start our investigation than to look at the linting setup used in the eslint repository itself!
Source: Speeding up the JavaScript ecosystem - eslint, an article by Marvin Hagemeister.