super-linter: _LINTER_RULES rules doesn't exist

@gon1332 try adding VALIDATE_JAVASCRIPT_ES: true, and also try replacing LINTER_RULES_PATH: ${{ github.workspace }} with the directory where your .eslintrc.json file is located. For example, if your .eslintrc.json file is located in your repo’s root directory, your LINTER_RULES_PATH ENV VAR should look like LINTER_RULES_PATH: / notice that the forward slash is used to define the root directory.

Also, take a look at: https://github.com/github/super-linter/blob/master/docs/using-rules-files.md to learn more about how to tell super-linter what your custom rule filenames are and where they are located.

Hopefully this helps. If not, please let us know.

@ferrarimarco @admiralAwkbar

What do you folks think about eliminating the LINTER_RULES_PATH env var, and replacing it with functionality that just searches the user’s repo for a config file if the user has set a config file env var in their super-linter linter.yml?

For example, if a user has set a config file env var in their linter.yml such as MARKDOWN_CONFIG_FILE: .markdownlint.yml, super-linter could search the entire repo for .markdownlint.yml and then pass the path and file name to the markdown linter binary upon execution.

This functionality would be similar to how cosmiconfig works. Some linters already have cosmiconfig functionality built in such as stylelint. Folks may find it helpful if we were to apply this functionality to all linters in super-linter that support config file env vars such as stylelint, hadolint, markdownlint, eslint, pylint, robucup etc.

Alternatively, updating the documentation is also a good idea. I’d be happy to contribute some text to the README to help with this issue 😄 if you folks would like me to.

@josephmarino It works now!! I had it all that done. I just needed a complete new Pull Request to have it to work. I kept committing on the test PR I opened days ago. Just learned it wasn’t the right way to test this change 😄

As a inexperienced Super-Linter user, documenting the use of how env vars are required to be used together would have likely made this a non-Issue.

However, without fully understanding the intended developer experience of Super-Linter, as a user I think I’d first expect this to work by setting only one env var and that a the base/root location would be based on my project and not the vendor specific workspace.

My opinion on that point is based on the fact that my workflow involves linting locally first, typically via an IDE, which expects configuration files placed in the root of project or root of the project’s specific directory (in my example case, docs/ for markdownlint.yaml).

Thank you for this tool!