Conflict between TypeScript & React ESLint rules about code-quality-tools HOT 8 CLOSED

Yes please :) We are probably going to do that. Need to double check that with @robertrossmann and @prichodko

from code-quality-tools.

@lucasconstantino The problem with extensions should now be fixed in the latest versions of rulesets.

Please note that:

• ESLint will only lint those files whose extensions are provided on the commandline, only .js is linted by default
• ESLint will use the parser and rules defined in your eslintrc file for all file types, unless you override the configuration for those files using the overrides: [] feature. I am not sure if it is possible to override the parser, so it might be difficult to lint both vanilla JS & TS sources in one go, or any other combination of source types.

Let me know if I can help with your setup or if you discover any other incompatibilities or conflicts between these two rulesets. The way you include the rulesets was the intended usage and if something does not work it's a boog. 🐛

from code-quality-tools.

@lucasconstantino I am going to close this issue as I believe the inconsistencies you reported have been fixed. In case you find more please do let us know so we can fix them all for everyone! ❤️ Thanks!

from code-quality-tools.

Extensions

@strv/eslint-config-react builds on top of @strv/eslint-config-base, which states:

// simplified .eslintrc setting path
"settings.import/resolver.node.extensions": [".mjs", ".es", ".js", ".jsx", ".json", ".node"]

@strv/eslint-config-react also builds on top of @strv/eslint-config-base, but overrides this setting as follows:

// simplified .eslintrc setting path
"settings.import/resolver.node.extensions": [".ts", ".d.ts", ".mjs", ".js", ".json"]

This difference is:

+ .ts
+ .d.ts
- .jsx
- .es
- .node

So far as I've searched, there is no way to perform combination of settings. Therefore, in order to use @strv/eslint-config-react and @strv/eslint-config-typescript together the current solution is to override this setting at the project's .eslintrc.js, such as follows:

// .eslintrc.js
'use strict'

module.exports = {
  extends: [
    '@strv/eslint-config-react',
    '@strv/eslint-config-typescript',
  ],
  settings: {
    'import/resolver': {
      node: {
        extensions: [
          '.js',
          '.json',
          '.ts',
          '.d.ts',
          '.mjs',
          '.es',
          '.node',
          '.jsx',
          '.tsx',
        ],
      },
    },
  },
}

Notice I didn't only join both arrays, but added .tsx, which was absent in both.

from code-quality-tools.

I think we should go ideally with eslint-config-typescript-react which will be importing needed stuff under the hood and extending needed rules

from code-quality-tools.

@dannytce you meen creating a new config?

from code-quality-tools.

@lucasconstantino When using TS language in combination with React, what are the module extensions that you need to be recognised?

For base, I think with the advent of Node.js 12 the "officially" supported extensions for a basic javascript are:

• .mjs
• .cjs
• .js
• .json
• .node

For react, the above remains, plus

• .jsx

For typescript, the base remains, plus

• .ts
• .d.ts
• .tsx

Is it needed for TypeScript to also recognise .jsx? Is .jsx a recognised file extension by the TypeScript compiler?

I am envisioning a relatively simple solution where we would simply extend this configuration value from base with some extra extensions and that should cover 99.9% of use cases.

from code-quality-tools.

@robertrossmann as far as I know, .jsx is not interpreted by TypeScript, but should certainly be resolved by ESLint: there is nothing preventing someone to have acutal .jsx files in a TypeScript based application, nor should there be - the same as we expect for .js files. The confusion here is that TypeScript does support JSX files out-of-the-box, which is rather opinionated.

@robertrossmann I've tried to tweak if .eslintrc.js files in order to properly extend configs, but the only way that seems to be possible is to actually import the configuration from the other file - which would be redundant with the extends key.

I've also tried to "resolve" the whole ESLint config using ESLint's API, but didn't dive much into it... there is a command line argument --print-config which does what I want: get a full, final ESLint config, which we could then programmatically extend, but the command is rather complex and it's logic doesn't seem to be available as an API.

Nonetheless, I totally agree with the idea of extending the real base config, just giving you a heads up on what this might mean.

from code-quality-tools.