CLI option for lint ignore directives

[l-cornelius-dol]

I have hooked up Deno to lint source files on-demand. But there are numerous linting rules which we, as a company, need to ignore. Adding them to every single source file would be highly cumbersome, and undesirable. I will absolutely get push back from developers who will simply refuse to lint their code entirely.

Is it possible to provide a global list of ignore rules for deno lint in the command line, either with an option or file listing the rules to ignore? If not, could this be added? These would have to be ignored for the purpose of reporting unused ignore rules actually embedded in the file.

Currently I have to do a kludge that involves prepending each file to be linted with my global list of directives to ignore, which means (a) that error lines are out by 1 because Deno sees the ignore line as part of the input source, (b) Deno reports a bunch of (ban-unused-ignore) errors, and (c) the reported filename is stdin instead of the actual file being linted (which breaks the editor link to the file & line in error).

[magurotuna]

Duplicate of denoland/deno_lint#166 (except for command line option)
this feature is of relatively low priority as far as I understand though, because the linter is trying to be opinionated as much as possible by providing users with almost no config.

FYI there is a standalone binary including the linter only, which is available on the release page of denoland/deno_lint. This binary is used for running lint on the denoland/deno repo, and has the capability of configuring what rules should/shouldn't be run via a config file. For a concrete example see .dlint.json. If you're interested in trying it out, please download and use it to see if it works well for your usecases, and give us a feedback.

[l-cornelius-dol]

@magurotuna : Thanks, I'll try that out today.

But do note that one of the reasons I've decided to base our dev tools on Deno is the ease with which it's kept up to date. Being able to simply run deno upgrade and it's done is exactly what a tool chain environment needs, coupled with Deno being a single executable. Manually updating dlint will be doable, but can't be automated and it's not nearly as clean as updating deno.exe. So I would like to see the ability to read the JSON default config added to the main Deno executable.

because the linter is trying to be opinionated as much as possible

I appreciate that, but I have to politely disagree. A linter should absolutely not force it's opinions upon other code -- you can't possibly know what's good and acceptable for our code base, and deno lint is not being used only on Deno's code, even if that's it's primary purpose.

I must add, you've all done amazing work with Deno, and it is appreciated. I am just looking to leverage that to the maximum extent possible. My devs will simply not lint the code if in their eyes it causes more work than the perceived value -- so I need to make it as easy as possible, and provide the maximum value for the minimum extra work.

[l-cornelius-dol]

@magurotuna : At the risk of being stupid... I don't see how to specify the JSON config file in the command line. Does this depend on the .dlint.json file being in a specific place by convention? Maybe in the same folder as dlint.exe?

[l-cornelius-dol]

@magurotuna : How do I use the configuration file with dlint? I've scoured the docs and issues and I'm just not able to find it.

[magurotuna]

@lawrence-dol
Sorry for the late reply! Partly because GitHub's recent activity has been made worse for me...
Anyway, you can pass --config=<path to config json> option to dlint, like dlint run --config=./.dlint.json.

But do note that one of the reasons I've decided to base our dev tools on Deno is the ease with which it's kept up to date.

Yes, I'm aware of that. I suggested using the dlint binary just for trial to see if it works fine for you. Give us a feedback whether you like it or not - I think it will drive this feature towards being introduced in deno lint.

[l-cornelius-dol]

@magurotuna : Thanks, that works like a charm. This is exactly what I'd like to do with deno lint.

[l-cornelius-dol]

BTW, allowing the full filename to be specified (as opposed to the folder and requiring the name to be .dlint.json) is exactly the right choice; first, I might want to use both dlint and deno lint with the same config; second, I wouldn't like .dlint.json on a *nix system which would make the file hidden to devs on those systems.

It would be useful for tool deployment if the --config was able to specify a location relative to the deno or dlint executable without requiring an environment variable (although I'm not necessarily saying a relative path should be relative to the executable rather than PWD).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[kitsonk]

Effectively a duplicate of #3179 which is slowly coming. When we address linting as part of adding configuration, we should help ensure it meets the needs here. Individual command line flags are likely impractical to implement (partly why we avoided it for so long).