Not a fanboy. But I'll go through my reasoning anyway. ---------------------------------------------------------------- ## Eslint We're on the same page that

Not a fanboy. But I'll go through my reasoning anyway. ---------------------------------------------------------------- ## Eslint We're on the same page that: - heuristics work until they don't - we'd all rather have false positives than missed positives - Having something is better than nothing - ESLint fits it's roll well for now I've been using node since the 0.x days and used iojs while it was ahead, I've gone from jslint -> jshint -> eslint -> tslint -> eslint (because it supported ts) + sonarlint -> now (which is rome tools in editor, and sonarlint to catch what rome tools doesn't support yet). The one problem I've had transitioning projects through each linter is just the amount of crufty exception comments to disable rules that ends up through my code. I've found that I can get rid of a lot of those by setting up my configs and turning on most of the strict modes. As for promises specifically, I've ended up needing to fire off a lot of floating promises in the last 18 months. There's a lot of firing things off to set values in things that may not exist anymore. (I've noticed it happens a lot a lot around using Promise.race to make code that gracefully recovers in chaotic environments) The false positives got too much so I disabled the rule (and at a later point moved away from eslint altogether). There's also some tricky things with catching floating promises when working with frameworks that can deal with super hard to debug side-effects. So now I have: - floating promises where for specific situations I don't want to catch their errors and have them throw up to the next layer - floating promises that are conditionally caught - floating promises that are actually a wrapped promise that fails as an uncaught promise should, but also conditionally triggers the debugger or logs out a trace. I use different approaches depending on the situation. Maybe for you, the only situation you need to deal with is catching all promises (in which case you should continue using ESLint then turn off that rule when TS gets the correct promise handling detection), but for me it causes more trouble than it fixes. ---------------------------------------------------------------- ## Images If I had to do what you suggested, I would have actually just used sharp, but after reading your comment about dependencies, I wasn't sure if you would accept that answer. I suggested two alternatives: 1. Compiling an existing solution into web assembly to box up that functionality and call into it. It could be ImageMagick, libpng, libspng, libvips, etc... I suggested ImageMagick because that tends to be the go-to for when someone has a specific setting in mind (usually due to a legacy system). 2. Setting up streams and using TypedArrays (which is what sharp uses anyway)