nfour / eslint-config-standard-typescript-prettier

A simple eslint config for modern TypeScript projects.
MIT License
22 stars 8 forks source link

Possibly inconsistent behavior: rules and file types #2

Closed JeffSpies closed 2 years ago

JeffSpies commented 4 years ago

Hi again. :)

First off, I hope you continue maintaining this project. This is by far the easiest way to get estlint+standard+tyepscript working given the known issues in making these things work together when doing so manually. Thanks!

I have encountered a couple of issues though that I wonder if you can comment on (admitting that they're quite likely my fault):

1) I'm seeing at least one standard-inconsistent rule in ts files. I believe Standard wants a space before function parens (space-before-function-paren), but when using this in my library, auto-fix based is removing those spaces. EDIT: OK, it seems eslint and prettier are fighting and in my case. So this is the rabbit-hole that led me here in the first place: Prettier refuses to add options that make it Standard-compliant, so prettierx was created, but then editors plugins don't know about prettierx. Standard actually has a formatter (and editor plugins), but there's a bug for TS support so they recommend StandardX. Luckily plugins often recognize StandardX, but standardx has a known bug as well. :P 2) I'm developing with Quasar/Vue, which does allow for TS, but is currently a mix of JS and TS. When installing with the recommendations in the README, I was seeing TS errors in JS files (e.g., a lack of typing). I had to do the following in my existing .eslintrc.js file:

const config = require('eslint-config-standard-typescript-prettier')
module.exports = {
  STUFF FROM QUASAR
  overrides: [
    {
      ...config,
      files: ['**/*.ts', '**/*.tsx']
    }
  ]
}

Should I have been able to just do the appropriate mixing of config? For example

const config = require('eslint-config-standard-typescript-prettier')
module.exports = {
  ...config,
  rules: {
    ...config.rules,
    RULES FROM QUASAR
  }]
}

Because I'm not sure if the second problem is causing the first or if I'm just missing something important, I've included both in this one issue. If you tell me they are both real issues, I'll go back and add them to the tracker as separate issues.

Thanks again!

nfour commented 4 years ago

The second example, from what I've learned, should work well - although - overrides may be necessary due to all of the extending that happens with all of these config libraries. If you configure the use of the tsconfig inside the eslint config, and within that allowJs, my understanding is that the latest version of eslint (7+) should utilize those file extensions without having to provide them.

For the first issue, you're right that prettier overrides eslint standard.

For example

// eslint-disable-next-line prettier/prettier
    get pic () {

The above ill allow the space after the function method name in practice.

I've not gone into how to resolve this because I'm interested in having everything autofix in a deterministic way, which it luckily still does in spite of the conflicts.

If you find out how to configure standard with prettier without awkward dependency stuff that might be nice.

My understanding is that the upsteam eslint config schema is undergoing a significant breaking change refactor so we also may wish to wait for that.