Setting options per project about jslintmate

[rondevera]

Hi Arne,

Definitely. The setup steps are documented in the readme:

1. Set up .tm_properties: https://github.com/rondevera/jslintmate/#textmate-2 (just the "Project setup" part)
2. Set up an options file (separate from .tm_properties): https://github.com/rondevera/jslintmate/#keep-an-options-file-in-your-project

Here are some example options files to get you started: https://github.com/rondevera/jslintmate/tree/master/Support/config/

This lets you have separate JSLint/JSHint options per project, and you can run JSLintMate with either JSLint or JSHint for each project as needed. However, the TM_JSLINTMATE_DEFAULT_LINTER setting is the same across all projects.

Cheers,
Ron

[arnemart]

Yes, I am aware of this, but I am talking about overriding TM_JSLINTMATE_DEFAULT_LINTER, TM_JSLINTMATE_JSHINT_OPTIONS_FILE, TM_JSLINTMATE_JSHINT_FILE and the like in .tm_properties, on a per-project basis. Is this possible?

[rondevera]

Aha, thanks for clarifying; I like your idea. It looks like environment variables stored in .tm_properties are overridden by those in the "Linters" and "Options Files" settings. However, try this:

1. In .tm_properties, set something like:

   TM_JSLINTMATE_JSHINT_OPTIONS_FILE = "$projectDirectory/project/specific/path/to/jshint.json"
   

2. In the "Options Files" setting:

   {  name = 'TM_JSLINTMATE_JSHINT_OPTIONS_FILE';
      value = '$TM_JSLINTMATE_JSHINT_OPTIONS_FILE:~/.jshintrc';
   },
   

The latest version of JSLintMate supports fallback options files, so this should set it up to first check existing environment variables (as set in .tm_properties), then fall back to your personal .jshintrc. (Tested this just now.)

This is just for options files, though. TM_JSLINTMATE_DEFAULT_LINTER doesn't support the same colon syntax for fallbacks, so the same trick wouldn't apply.

I can picture two solutions:

1. Add support for colons inside TM_JSLINTMATE_DEFAULT_LINTER, allowing it to check for an existing environment variable before using its own, user-chosen default. The commands that ship with JSLintMate could even change to respect .tm_properties by default with the technique above.
2. Add support for new TM_JSLINTMATE_PROJECT_DEFAULT_LINTER, TM_JSLINTMATE_PROJECT_JSHINT_OPTIONS_FILE, and other settings. These would be used only in .tm_properties, so that it's very clear how they differ from the existing regular options. Downside is that they don't apply to TextMate 1.

What do you think?

[arnemart]

Thank you for a very detailed reply :-) I am already using the colons option for setting a custom .jshintrc per project, and that works great. Having a similar option for selecting which linter to use would solve my woes (such as they are), and for me either of the solutions you outline would work. Feel free to select the option that suits you best. If you are busy, I could look into fixing it myself, and submitting a pull request.

[darobin]

Additionally, I would love to be able to disable JSLintMate entirely on a given project. Some times I have to contribute to projects that really don't follow any manner of style that's enforced through JSHint, and I'm not in a position to change that (either because it's not my project, or because I don't have time immediately to bring it up to par).

In such cases the tooltip on save gets really annoying. I have to resort to disabling JSLintMate globally, which I then have to re-enable for my other projects (or, more generally, which I then forget to re-enable until I shoot myself in the foot).

[MokoJumbie]

The JSHint docs state:

JSHint will look for this file in the current working directory and, if not found,
will move one level up the directory tree all the way up to the filesystem root.

Why doesn't JSLintMate follow that convention? It's so straightforward and is most likely the convention that your collaborators will be using.

[rondevera]

@MokoJumbie It's definitely a nice convention from node-jshint, and it's been on my todo list to support it. The catch is that it would cause a lot of confusion/complications with the existing TM_JSLINTMATE_{JSLINT,JSHINT}_OPTIONS_FILE settings. I'd like to support both systems in a future 1.x release, then remove TM_JSLINTMATE_{JSLINT,JSHINT}_OPTIONS_FILE in 2.0.