21–30 of 93 posts
I have been waiting for this release for the new possibility to include a comment in eslint-disable-{next-}line: // eslint-disable-next-line no-console -- Here's a description about why this configuration is necessary. console.log('hello'); https://eslint.org/docs/user-guide/configuring#disabling-rul...
I have been waiting for this release for the new possibility to include a comment in eslint-disable-{next-}line: // eslint-disable-next-line no-console -- Here's a description about why this configuration is necessary. console.log('hello'); https://eslint.org/docs/user-guide/configuring#disabling-rul...
How is that different than: // Here's a description about why this configuration is necessary. // eslint-disable-next-line no-console console.log('hello');
I have been waiting for this release for the new possibility to include a comment in eslint-disable-{next-}line: // eslint-disable-next-line no-console -- Here's a description about why this configuration is necessary. console.log('hello'); https://eslint.org/docs/user-guide/configuring#disabling-rul...
How is that different than: // Here's a description about why this configuration is necessary. // eslint-disable-next-line no-console console.log('hello');
Looking at one suppression in one place it doesn't make a big difference.
It will help a lot with whole-project search results, though, if you're trying to e.g. fix all the places you had to suppress X because of Y.
There is a rule in eslint that warns you when a promise is dangling and hasn't been handled. Please use that rule . So many bugs in the JS world is because of dangling promises.
I haven't done TypeScript/JavaScript in a while. What's the status of ESLint taking over from TSLint (for both the tool itself and the vscode extensions)?
I have been waiting for this release for the new possibility to include a comment in eslint-disable-{next-}line: // eslint-disable-next-line no-console -- Here's a description about why this configuration is necessary. console.log('hello'); https://eslint.org/docs/user-guide/configuring#disabling-rul...
How is that different than: // Here's a description about why this configuration is necessary. // eslint-disable-next-line no-console console.log('hello');
1. Sometimes there's already a comment on the preceding line commenting the logic, and the new comment explaining ESLint would have to go awkwardly in-between.
2. Sometimes it's just complicated to word the comment if it can't be on the same line.
3. Sometimes eslint-disable-line is in a place where it would be ugly to have a comment above. Here are two examples from my current project, both from cases where the disable is right after a closing curly brace:
} as any // eslint-disable-line @typescript-eslint/no-explicit-any
}, [map]); // eslint-disable-line react-hooks/exhaustive-deps
Feature request #1: https://github.com/eslint/eslint/issues/11298
Feature request #2: https://github.com/eslint/eslint/issues/11806
RFC: https://github.com/eslint/rfcs/tree/master/designs/2019-desc...
Next up: an ESLint rule that makes the comment obligatory for disable directives.
There is a rule in eslint that warns you when a promise is dangling and hasn't been handled. Please use that rule . So many bugs in the JS world is because of dangling promises.
I can't speak to the front-end, but there are plenty of situations in dealing with node where the correct thing to do is to throw a fatal error. If you have properly setup handlers for the end of the process lifecycle I don't see what the problem is.
Ah ESLint, the most necessary bane of my existence. Good work to the team for the update.
I switched to jshint and have lived a much happier life.
There is a rule in eslint that warns you when a promise is dangling and hasn't been handled. Please use that rule . So many bugs in the JS world is because of dangling promises.