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

Report lint issues inline, not on first char of file, for Vue and Svelte #2103

Open
bmulholland opened this issue Jan 8, 2024 · 4 comments
Labels
help wanted Extra attention is needed kind/enhancement New feature or request

Comments

@bmulholland
Copy link
Contributor

Is it possible to resolve the limitations that results in the workaround introduced at #1346 ?

@bmulholland
Copy link
Contributor Author

bmulholland commented Jan 8, 2024

Amongst other things, I expect this limitation means that https://github.com/reviewdog/reviewdog (and similar, diff-based approaches) won't fail PRs that introduce linting errors, meaning we lost a critical enforcement of these policies.

@dimaMachina
Copy link
Owner

as I remember graphql-tag-pluck returns compiled code for vue/svelte files, as result - location of extracted documents will be incorrect from the source file

Maybe there is some workaround to parse vue/svelte files with vue/svelte parsers and run graphql-eslint processor on extracted js/ts code-blocks, example

  overrides: [
    {
      files: ['**/*.svelte'],
      parser: 'svelte-eslint-parser',
    },
    {
      files: ['**/*.svelte/*.{js,ts}'],
      processor: '@graphql-eslint/graphql',
    }
]

PR welcome

@dimaMachina dimaMachina added help wanted Extra attention is needed kind/enhancement New feature or request labels Jan 12, 2024
@bmulholland
Copy link
Contributor Author

bmulholland commented Jan 12, 2024

Oh interesting, yeah that limitation makes sense. Thanks for the detail, I appreciate it. I suspect the strings are often the same, so also a naive string match could work to correct the locations?

I don't quite understand how the workaround with parsers would maintain location information. Why wouldn't that have the same limitation?

@bmulholland
Copy link
Contributor Author

Just to jot down an idea I had here: pluck could add a magic comment at the top of its output, which includes the location it was extracted from. Then this could be read and added as an offset when reporting the lint.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed kind/enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants