Steve Taylor

It’s an issue for the reasons outlined above. There are already plenty of rules that, when applied, restrict the usage of language capabilities that some people may find useful. It’s...

>What would happen when you wanted to use the Foo component and widget in the same file? At that point, I'd consider naming things more appropriately. For example, I'd look...

Let's also consider the following case (and I've been guilty of this before): ```js export default function getDefaultFoo() { // .... } ``` ```js import getMainFoo from '../foos/normal'; ``` This...

> the point of a module is that you think about one module (file) at a time. It would be nice if feature tickets and modules were nicely aligned. In...

> Effectively this rule would disable a major feature of the language These rules also disable major features of the language: * `import/no-anonymous-default-export` - cannot `export default () => {}`,...

You’re smarter than me, then! The issue is that when there are a number of similarly named functions with a similar purpose that return the same type of object, but...

Not the same file. Spread throughout the same project.

When I'm working on a feature/bug task that involves work across multiple files, which is almost every task ever. The use case is not a typical open source Node.js library...

If you want to find all usages of a function or class throughout your project, and you don't have a fancy IDE that can find all usages regardless of name...

If you want to have a crack at doing this yourself, you can use the `getChangedPackagesSinceRef` function exported from [`@changesets/git`](https://github.com/atlassian/changesets/tree/main/packages/git), which gives you the parsed package.json of every directly changed...