merkle-open / eslint-config Goto Github PK

https://www.npmjs.com/package/eslint-plugin-react-hooks

example:

AppNavDrawer.propTypes = {
    docked: PropTypes.bool.isRequired,
    style: PropTypes.object,
    onRequestChangeNavDrawer: PropTypes.func.isRequired
};

current config:

'react/sort-prop-types': [2, {
    ignoreCase: true,
    callbacksLast: true,
    requiredFirst: true
}],

Does it make sense to have eslint 5 support?
Migration Guide eslint 5

What do you think?

Comma dangle decreases the quality of git-history and tends to cause merge conflicts as you have to change lines although you are not changing it.

The rule comes from >=IE7 because IE used to handle the comma dangle as syntax error.
For IE8+/Chrome/FF/Safari/Node that's not and issue anymore.

Do you see further benefits to follow this rules?
I would suggest to turn this rule off.

Would it make sense to have eslint 4 support?
Probably it's not that easy, plugins also have to be updated: http://eslint.org/docs/4.0.0/user-guide/migrating-to-4.0.0
What do you think?

By using webpack with dynamic imports you can use a inline comment to name the file:

const { wait } = await import(/* webpackChunkName: "wait" */ './wait');

Eslint config does not allow this becauseno-inline-comments is enabled

At the beginning of October the new version 8 of eslint was published.
We should either note in peerDependencies that the configuration should be used up to eslint verison 7 or ensure compatibility to version 8

currently dynamic import's failing because there is no parser defined.

With the release of v0.9.3 the version of the typescript eslint plugin and parser got an update from 3.10.1 to 4.8.1 (see here.

It seems that with v4 of typescript-eslint you now have to manually define globally defined namespaces in your configuration file (see Typescript-eslint FAQ reference).

If you do not do this, eslint will throw no-undef related errors although the namespaces are accessible over typescript, e.g.:

const CustomTag = props.tag as keyof JSX.IntrinsicElements; // --> 'JSX' is not defined. eslint(no-undef)

So: Does it make sense to apply the recommendation of typescript-eslint, and automatically opt out of the no-undef rule altogether as soon as we are using our typescript related configurations?

Hey,

I don't always want to add JSdoc comments to constructor, render and all the lifecycle methods.
Could we please ignore those methods?

1. Does it makes sense?
2. Collect use-cases
3. Describe problems and how the can be solved

Some examples

Results

No. 2:

• Sitecore JSS (naming could cause errors)
• Unix vs. Windows (could cause errors)
• git rename files lowercase to pascal case could also cause errors

Next steps / plan

• Research existing repositories
• take over repo or folk

Useful existing plugins

• https://github.com/dolsem/eslint-plugin-filename-rules
• https://github.com/loeffel-io/ls-lint
• (https://www.npmjs.com/package/eslint-plugin-filenames, selaux/eslint-plugin-filenames#48)

Features

• lint all file types
• allow regexp per directory

Create pluggable ESLint configuration for Angular projects as part of the @namics/eslint-config.

First evaluate if this is a good idea. Maybe use recommendations from Angular itself.

I'm getting this error when using this config with node 4.x and matching npm version 2.x:

Error: Failed to load plugin import: Cannot find module 'eslint-plugin-import'
Referenced from: @namics/eslint-config/configurations/es6-browser.js
Referenced from: <...>/.eslintrc.js
    at Function.Module._resolveFilename (module.js:325:15)

the flat structure of npm 3 seems to fix the problem
but i couldn't find a fix for npm 2

what to do?

• drop support for node 4 completely?
• drop support for npm 2
• find a way to solve this
• ...

Some days ago eslint version 6 was released.
Since there are some breaking changes we should invest some time to make tis configuration compatible.

I like the idea of showing tips and improvements into linting errors or warnings. See: https://addyosmani.com/blog/disallow-imports/

What do you think about adding:

1. Such a rule
2. Use some messages into our rules. Maybe better only on project basis as a custom rule – because there is a wide range of potentially big libraries out there?

JSX is getting used by other libraries as for now VueJS.
If using a mono-repository with hoisting it will lead to a typescript conflict where it is not able to simultaneously extend "Element" with ReactElement and VNode.

Could we move @types/react and @types/react-dom to devdeps. or create separate packages for different libraries e.g. (@namics/vue-eslint-config)?
Would love to contribute.

Looks like @Dash4 is not maintained anymore. We should think about removing this package/functionality. In additional: currently it introduces vulnerabilities in our dependencies (moderate).

Create pluggable ESLint configuration for Vue.js projects as part of the @namics/eslint-config.