settings from rubocop.yml are ignored

[LeEnno]

I have an example haml file:

- some_val = 123456
= some_val + 1

My rubocop.yml says:

Style/NumericLiterals:
  Enabled: false

When cding to /path/to/project and running haml-lint test.haml I get 1 file inspected, 0 lints detected. Works.

Sublime Console tells me the following:

SublimeLinter: #17 linter.py:1636     Running ...

  /path/to/project  (working dir)
  $ /path/to/.rvm/bin/rvm-auto-ruby -S haml-lint /var/folders/l2/j37t2cjs5ssgcgsrk1xyt1x40000gn/T/tmpl2k7vx.haml

SublimeLinter: #17 linter.py:1202     hamllint: output:
  /var/folders/l2/j37t2cjs5ssgcgsrk1xyt1x40000gn/T/tmpl2k7vx.haml:1 [W] RuboCop: Style/NumericLiterals: Use underscores(_) as thousands separator and separate every 3 digits with them.

  1 file inspected, 1 lint detected

So haml-lint in Sublime ignores my settings in rubocop.yml.
SublimeLinter.sublime-settings does not have any settings regarding haml-lint.

I'm using

• Sublime v3.2.2
• SublimeLinter v4.14.0
• SublimeLinter-haml-lint v2.1.0

Unfortunately I can't say for how long this has been the case.
Any ideas? Happy to help debugging.

[kaste]

How does haml look up the configuration?

[LeEnno]

Don't know, but it seems like it delegates the heavy lifting for the rubocop gem.

[kaste]

Hm, you point to the parser.

https://github.com/sds/haml-lint#configuration
https://github.com/sds/haml-lint/blob/5cd2e0ae5a2aeddbe5731bd0d66bbb7a4a17ed40/lib/haml_lint/configuration_loader.rb#L11

[LeEnno]

Sorry, misunderstood your question. I thought since it‘s an issue with rubocop you were interested in where that is coming from.

So yeah, haml-lint expects a haml-lint.yml (which works fine) but also integrates with rubocop (which does not work for me).

[braver]

It loads the configuration based on the directory haml-lint is being run from, ascending until a configuration file is found.

[LeEnno]

This is just me guessing, again, but maybe this bit from the linters documentation helps:

You can also explicitly set which RuboCop configuration to use via the HAML_LINT_RUBOCOP_CONF environment variable. This is intended to be used by external tools which run the linter on files in temporary directories separate from the directory where the HAML template originally resided (and thus where the normal .rubocop.yml would be picked up).

Maybe haml-lint does not executed in the correct context, so it doesn't find path/to/projetc/.rubocop.yml.

If there's anything I can do to help investigating this let me know.

[kaste]

👍 Yeah that's it probably. See also https://github.com/dense-analysis/ale/blob/2b785688ead505dcbc1007374d3dca9914aa247a/ale_linters/haml/hamllint.vim#L10-L33

[kaste]

So, it looks up a .haml-lint.yml based on the working dir (as per the doc cited), but the rubocop.yml must be set explicitly because it is looked up by looking at the filepath we pass in which is a temp file. 🤷 funky

[kaste]

The work-around or test is to set it in the SL settings.

"linters":
  "haml-lint":
     "env": {
        "HAML_LINT_RUBOCOP_CONF": "${folder}/.rubocop.yml"
    }

If that works a PR can be made to automate this.

[LeEnno]

Unfortunately this does not work. Not with ${folder}/.rubocop.yml and also not with the absolute path :(

[kaste]

Where you're standing here? Do you feel comfortable and can recreate what SublimeLinter does on the command line. Basically given the info when you set debug to true. T.i. can you make it fail on the command line?

I'm not Ruby developer so I would need a simple repo with basic instructions to fully dig into it. For example I can't write haml and a valid ruboconfig. 🤫

[LeEnno]

Ok, I try my best to give a reproducible test case.

First You need to have ruby and also rubygems installed. Afterwards you need to run gem install haml_lint to install haml-lint executable.

As for the actual source files you need kaste.haml und rubocop.yml.

Contents of kaste.haml:

- some_var = 123456
%p
  = some_var

Contents of rubocop.yml:

AllCops:
  NewCops: enable

Style/NumericLiterals:
  Enabled: false

If you run haml-lint kaste.haml you should get 1 file inspected, 0 lints detected as output. No lint offenses.

To recreate what the plugin does, the haml-file needs to be copied elsewhere. So if you run ...

cp kaste.haml /some/where/else/kaste.haml
haml-lint /some/where/else/kaste.haml

... you should get a lint offense along the lines of:

/some/where/else/kaste.haml:1 [W] RuboCop: Style/NumericLiterals: Use underscores(_) as thousands separator and separate every 3 digits with them.

Possible fixes:

• do not copy the file elsewhere because why?
• copy the file to the project's root and delete it afterwards
• change the command to include HAML_LINT_RUBOCOP_CONF, i.e. HAML_LINT_RUBOCOP_CONF="/path/to/project/.rubocop.yml" haml-lint /some/where/else/kaste.haml

I did not consider the environment dance with rvm because it's not necessary in this case.

Hope this helps. If I can assist any further, let me know.

[kaste]

Okay, setting env works for me.

"hamllint": {
            "env": {
                "HAML_LINT_RUBOCOP_CONF": "${folder}\\.rubocop.yml"
            },
        },

Note that hamllint, in my previous post I spelled it haml-lint.

[kaste]

A bit ridiculous because that exact config was in the last version of this plugin. Removal 5bfe0fb (#10)

[LeEnno]

That totally explains why it used to work for our team. Fun fact: now we have

• a gem called haml_lint,
• a cli command called haml-lint and
• a sublime linter namespace called hamllint 😱

What is the best way to go from here? Documenting this (probably not too rare) use case? Will gladly create a PR. Reverting parts of the mentioned commit? Or do you plan to give this plugin a proper rewrite to fix all those other weird issues (tempfile, executable and use_bundle_exec settings not being implemented)?

[kaste]

We should set the env variable if possible. But if it throws if there is no such file we shouldn't take the same kinda static approach t.i. just assuming it is in the root folder.

Executable can be fixed by removing the ruby -S from cmd which is really a mistake.

I consider renaming this plugin to haml-lint although that's breaking (everyone has to change its settings) but hamllint is so confusing, and the double l in the middle is ugly.

The other stuff must be implemented in SL core.

[kaste]

Isn't this solved now that we use stdin? We don't use the indirection ruby -S anymore so that seems solved too.

[LeEnno]

I don't need the manual config anymore, indeed. Thx 🙏