Pass filename to stylelint

[cristianl]

When working with stdin, stylelint needs the filename to determine the syntax of the file.

This fixes a bug: all files would be linted as CSS, so SCSS files that are not plain valid CSS files would get a CssSyntaxError.

[jo-sm]

Hey @cristianl good catch! Thanks for working on this.

I think it makes more sense to pass a --lang or --language flag, rather than the filename. Although there is already a --file flag available, I intended it to be used for determining the configuration location, rather than the language of the file. Sorry if this was a little weird/confusing, and now I realize that I should probably rework how the configuration file location determination code works within stylelint_d.

Anyway, if you can change it to support the --lang or --language flag, and also ideally a way to alert the user if their language selection isn't valid, I'll merge this in. Internally you can use the syntax API option (see the Stylelint Node API docs about this flag) when passing to the actual stylelint process.

[cristianl]

Oh, I went with the laziest approach that would work without requiring modifications to SublimeLinter-contrib-stylelint_d. Something about nails and hammers...

Should I keep the codeFilename block or only support the --language flag? Plugins using stylelint_d would have to implement their own syntax detection, which seems wasteful.

Even when you pass codeFilename you can override the syntax, as the value of syntax always takes precedence over what stylelint infers from codeFilename.

[jo-sm]

Hmm, good point. Originally I would say only support the --language flag, but I think that's a valid argument to keep both. In that case, can you make a condition to warn the user if they use both flags, in case they have valid reasons to override the syntax from the filename? Otherwise it looks good and I'll merge it after that.

[jo-sm]

Hey @cristianl just wanted to check in on this, were you able to take a look at my comments?

[cristianl]

Hi @jo-sm, sorry for not replying sooner. I'm not sure I understand your request: should I warn the user that the value from --language will override the file extension?

[jo-sm]

Yeah, essentially the language flag will take precedence over the file extension, including if they supply both the --file and --language flags. I just want to make it clear to the user that if they supply both, that the --language flag overrides or has higher precedence than the extension/--file flag.

[cristianl]

Done. Let me know if it needs further changes.

[jo-sm]

Looks good, thanks for the PR!