3 ms·

ESLint does an amazing job in detecting floating promises. I've not had it miss one, ever. When adding this to a project, I've discovered multiple accidental bu

ESLint does an amazing job in detecting floating promises. I've not had it miss one, ever. When adding this to a project, I've discovered multiple accidental bugs due to a missing "await" keyword--bugs that were extremely subtle and intermittent in many cases. The only thing it can't do is determine that you actually did handle the promise later. Which is fine. It's a LINTING RULE, and false positives are the name of the game. What's BAD is when you accidentally miss handling a promise at all. It's an invisible error without the linting rule. Your other comments...don't even make sense. You're going to build a Lanczos filter by hand? Or you're only going to ... compile ImageMagick to WebAssembly?!, ... an implementation which is tremendously slower (nearly unusably so for large images) than that of Sharp: https://www.npmjs.com/package/sharp https://www.npmjs.com/package/sharp ... which is simply an import away? No, what you're doing is called "motivated reasoning." You've concluded that Deno is the best, and you're reinterpreting all of my complaints in convoluted ways to support your predetermined conclusion. Standard fanboy behavior. Or troll behavior. I cite Poe's Law as why it's impossible to tell the difference.

spartanatreyu 3y ago
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)

spartanatreyu 3y ago

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)