Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possibly inconsistent behavior: rules and file types #2

Closed
JeffSpies opened this issue Jul 5, 2020 · 1 comment
Closed

Possibly inconsistent behavior: rules and file types #2

JeffSpies opened this issue Jul 5, 2020 · 1 comment

Comments

@JeffSpies
Copy link

JeffSpies commented Jul 5, 2020

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
Copy link
Owner

nfour commented Jul 7, 2020

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.

@nfour nfour closed this as completed Jan 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants