Support syntax-specific ESLint parsers for new unsaved buffers

[dndrsn]

ESLint plugins like eslint-plugin-yaml often depend on file name matching to parse specific file types. For example...

  overrides: [
    {
      files: ["*.yaml", "*.yml"],
      parser: "yaml-eslint-parser",
    },
  ],

Linting a new, never saved buffer that requires a syntax-specific parser (after manually setting the buffer syntax) does not work properly. ESLint has no way to know the override parser:

New never saved buffer command:
cat <buffer 268> | /path/to/eslint --format json --stdin

Previously saved buffer command:
cat test.yml | /path/to/eslint --format json --stdin --stdin-filename /path/to/test.yml

Not sure if there is any (clean) way to support this. One possible solution would be to pass a dummy filename via --stdin-filename for the buffer based on the buffer's syntax type. That would probably require a map of selectors to dummy file names/extensions.

The primary use case I have for this is using a new buffer as a scratchpad. The workaround is to just save to a temporary file with the correct file extension, but that can be tedious. Hope that is somewhat clear. Thanks.

[kaste]

Sounds reasonable to solve this. But how? Have you checked that a dummy filename would actually solve the problem? Maybe adding --plugin x is the better fix?

Can you actually implement this?

[dndrsn]

I tested from terminal with a saved file. This does not work correctly...

cat test.yml | /path/to/eslint --format json --stdin

... but this does ...

cat test.yml | /path/to/eslint --format json --stdin --stdin-filename __buffer__.yml

Which seems to confirm that it would/could work.

I also tried to force the issue, as a test, to see what would happen by adding the following setting to the linter config:

"args": "--stdin-filename __buffer__.yml",

That works correctly until a valid warning/error is produced because Sublime linter is now looking for a file that doesn't exist based on parsing the ESLint output:

SublimeLinter: #44 linter.py:1356     WARNING: eslint reported errors coming from '/path/to/__buffer__.yml'. However, reading that file raised:
  [Errno 2] No such file or directory: '/path/to/__buffer__.yml'.

It seems, in theory, this would work if logic were added when processing a new buffer to:

1. add a dummy --stdin-filename
2. replace the dummy filename parsed from the ESLint output with the appropriate buffer reference

My thinking for this approach vs. something like --plugin x is that it keeps the ESLint config hierarchy intact and out of the linter config, and supports more complex/nuanced filename-based logic that many not be as simple as use/don't use specific plugin.

Can you actually implement this?

I could take a shot and try to stumble through it. Not exactly my wheelhouse by I could probably figure it out. I'll try to find some time to take a look.

[kaste]

I don't like the './__buffer__.yml' aka dummy approach. It just looks brittle. Always some tool in the chain might want to actually depend on that file to be real. We also at least indicate a path where that file is located and eslint config might kick in with folder/path based rules, ignores and what not. What path should we actually construct here. A file sibling to package.json? 🤔

[dndrsn]

Always some tool in the chain might want to actually depend on that file to be real.

This approach only applies to never-saved buffers so anything in the toolchain that depends on a real file would already not work as is.

The linter sees the "dummy file" as being located in the project root which is no different than what it already does for a never-saved buffer.

Basically this approach works exactly like it already does for a never-saved buffer, it just provides additional context to the linter for file-extension dependent overrides.

I created a PR for a working solution: #326. If follows the same basic approach that is actually already in place to replace the filename <text> in the linter output with stdin. Essentially it is just extending what is already being done for never-saved buffers.

This could be further improved by moving both the map of ESLint plugins to selectors and the map of selectors to dummy file extensions to the settings file.

[kaste]

Fixed by #326