Some haml-lint lints are showing, but others aren't!

[frothedoatmilk]

This one is a bit strange: only some of the lints are coming through when running haml-lint: Say I have this partial in Rails:

%li.list-group
  .lead
     = @user.name

If I run this through haml-lint, I get a lint:

<relative path>:5 [W] InstanceVariables: Avoid using instance variables in partials views

But no error/warning shows in haml-lint. The diagnostic output shows no lint being detected, but my other lints are showing! I have a maximum line length set in my .haml-lint.yml of 120, which is working properly:

linters:
  ClassesBeforeIds:
    EnforcedStyle: id
  LineLength:
    max: 120

I'm not really sure what's happening. I've had some configuration issues before with haml-lint, which I thought I had resolved? Maybe I haven't? I might spend some more time debugging later, but I'm working right now and wanted to post this before I forgot

[frothedoatmilk]

For reference, here's a mildly sanitized version of the debug log:

SublimeLinter: #44 linter.py:1159     hamllint: linting '_partial.haml'
INFO:SublimeLinter.plugin.hamllint:hamllint: linting '_partial.haml'
SublimeLinter: #44 linter.py:937      hamllint: wanted executable is ['bundle', 'exec', '--', 'haml-lint']
INFO:SublimeLinter.plugin.hamllint:hamllint: wanted executable is ['bundle', 'exec', '--', 'haml-lint']
SublimeLinter: #44 linter.py:1714     Running ...

  /Users/lpate-af/Documents/<ooh secrets>  (working dir)
  $ /Users/lpate-af/.local/share/mise/shims/bundle exec -- haml-lint -c <the correct absolute path>/.haml-lint.yml /var/folders/t5/rlpzsmzx5kv01jw0xp5j9djm0000gv/T/tmp3w3mpo.haml

INFO:SublimeLinter.plugin.hamllint:Running ...

  /Users/lpate-af/Documents/<more secrets> (working dir)
  $ /Users/lpate-af/.local/share/mise/shims/bundle exec -- haml-lint -c <the correct absolute path>/.haml-lint.yml /var/folders/t5/rlpzsmzx5kv01jw0xp5j9djm0000gv/T/tmp3w3mpo.haml

SublimeLinter: #44 linter.py:1241     hamllint: output:
  1 file inspected, 0 lints detected
INFO:SublimeLinter.plugin.hamllint:hamllint: output:
  1 file inspected, 0 lints detected
SublimeLinter: #44 linter.py:1293     hamllint: No match for line: ''
INFO:SublimeLinter.plugin.hamllint:hamllint: No match for line: ''
SublimeLinter: #44 linter.py:1293     hamllint: No match for line: '1 file inspected, 0 lints detected'
INFO:SublimeLinter.plugin.hamllint:hamllint: No match for line: '1 file inspected, 0 lints detected'
SublimeLinter: sublime_linter.py:593  Linting '_partial.haml' took 5.56s
INFO:SublimeLinter.sublime_linter:Linting '_partial.haml' took 5.56s

Running bundle exec -- haml-lint -c ./.haml-lint.yml <file> from the project root gives three correct lints

And my current linter config:

{
    "debug": true,
    "linters": {
        "hamllint": {
      "executable": ["bundle", "exec", "--", "haml-lint"],
            "args": ["-c", "${folder}/.haml-lint.yml"],
            "working_dir": "${project_path}",
        },
    },
    "paths": {
        "osx": [
            "~/.local/share/mise/shims"
        ]
    }
}

mise is a version manager for ruby, it's been a problem in the past, it could be here, but I don't think so

[kaste]

I don't have a solution or really an idea here but (1) working_dir=$project_path seems odd. Why isn't that $folder?

Have you actually tried the exact command, environment on the CLI you see in the debug log? I think it is often helpful to replicate it on the CLI, t.i. to make the CLI fail.

[frothedoatmilk]

As to (1): From my understanding, they would produce the same thing, and making sure working_dir=$project_path ensures that (a) the right config gets loaded and (b) my version manager understands which version to use (since mise needs to pull from the nearest appropriate file)

But your second trick led to the problem! It only fails when the filename has an underscore before it. This is a rails convention, so likely the InstanceVariables linter doesn't run unless it sees the file has an underscore before it. Is there a reason we are using a temp file over just the normal file?

[kaste]

Is there a reason we are using a temp file over just the normal file?

Yeah sure, it's so that we can lint while typing. Has haml-lint learned to take the input from stdin?

[frothedoatmilk]

Seems so:

Usage: haml-lint [options] [file1, file2, ...]
...
-s, --stdin FILE Pipe source from STDIN, using FILE in offense when combined with --auto-correct and --stdin.

[kaste]

Hm, it's not on their page -> https://github.com/sds/haml-lint 🙄 Do you understand the explainer "using FILE in offense when combined with --auto-correct and --stdin". "--stdin" is set because that's the help for the flag "--stdin". Do they evaluate "FILE" in all cases because that's seems like causing the problem for you. If they don't, they don't see the leading underscore.

Other wise the change is to change $temp_file to --stdin ${file}in the cmd definition. You could probably try this. Just clone the repo in the Packages folder of Sublime and it will take over the installed one. Just delete the folder at some point later and the installed plugin from Package Control will be in charge again.

EDIT: Delete Line 21 tempfile_suffix = 'haml' probably :grin:

[frothedoatmilk]

Confirmed this works as intended:

∝  haml-lint --stdin <file> < /tmp/test.haml
<file>:5 [W] InstanceVariables: Avoid using instance variables in partials views

1 file inspected, 1 lint detected

yay!

[frothedoatmilk]

It's not on their page

I'll go bother them about that as well, seems pretty important to mention that... Also, I love that github simply didn't show your message until I posted!

[kaste]

It's not A CHAT; I have to leave for now. If you try a PR I can publish it tomorrow.

[frothedoatmilk]

It's not A CHAT

Yeah yeah >_<

If you try a PR I can publish it tomorrow

Will do right now