ipfs / eslint-config-ipfs

An ESLint Shareable Config used by IPFS project

IPFS is an open system to manage data without a central server

Check out our website at ipfs.tech.

For papers on IPFS, please see the Academic Papers section of the IPFS Docs.

License

MIT.

eslint-config-ipfs's Issues

esllint estree parser is very out of date

The eslint estree parser is very out of date:

See ipfs/aegir#1007

However due to dependency conflicts it may not be possible to upgrade until a new version is released here:

mightyiam/eslint-config-love#831

should allow use function-type in typescript types

ipfs/js-ipfs#3748

and also will easy write type by typescript overload

rename default branch to main

This repository for some reason goes against the conventional "main" branch and is using 'default' - not sure why? Can it be renamed to main for uniformity?

bug: config rule is preventing upgrade of @typescript-eslint/eslint-plugin from 5.62.0 to 7.5.0

see https://github.com/ipfs/aegir/actions/runs/8521375637/job/23339383672?pr=1492#step:5:11

& #211

Disable @typescript-eslint/no-this-alias rule

This rule stops you from doing things like:

const self = this

function foo () {
  return self.derp()
}

It prefers:

const foo = () => {
  return this.derp()
}

Which is fine. The problem is fat-arrows can't be generator functions and we use them all over the place so you have to use this aliases:

const self = this

function * foo () {
  yield self.derp()
}

Error: Failed to load plugin '@typescript-eslint' declared in '.eslintrc » eslint-config-ipfs#overrides[1] » ./ts': Cannot find module 'typescript'

typescript should be a dependency on the config as otherwise the rules don't work in standalone

Change @typescript-eslint/return-await to `in-try-catch`?

The default setting for @typescript-eslint/return-await is ['error', 'always'].

This disallows code like:

async function myAsyncFunction () {
  return someOtherAsyncFunction()
}

instead demanding:

async function myAsyncFunction () {
  return await someOtherAsyncFunction()
}

It doesn't seem to make any difference to the stack traces and we have other rules that catch floating promises so I'm not sure what value it adds, and it occasionally raises some eyebrows.

The rule comes from standard but it's not even clear that the standard maintainers are for this version of the rule.

It does have another mode which is "in-try-catch", this disallows this sort of thing, demanding and await before the return, which seems a bit more useful, as it looks like the author might think any rejection would be caught which is not the case:

try {
  return someOtherAsyncFunction()
} catch (err) {
  // phew!
}

Shall we switch this rule to "in-try-catch"?

Cc @whizzzkid @SgtPooki