New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

per folder linter settings #1474

Open
mathroc opened this Issue Jul 30, 2018 · 5 comments

Comments

3 participants
@mathroc

mathroc commented Jul 30, 2018

I know I can set per project linter settings. In a single "project" (eg: with a lot of repositories managed by different teams) sometimes I'd like to set different settings per folder (eg: use a different config file)

It could work by creating a project in sublime for each repositories but it would be quite cumbersome because it would mean we'd have to open a lot of sublime window to work across the many repositories

would that be in the scope of SublimeLinter?
thank you

@braver

This comment has been minimized.

Show comment
Hide comment
@braver

braver Jul 30, 2018

Member

Linters like eslint that have config files, will search "up" from the current file to look for their project's root and configuration. In most cases using the linter's native configuration enables this behaviour without you having to specify anything in SublimeLinter.

We lean on Sublime Text's API's for merging different levels of configuration, ensuring that it just works everywhere and works just like all other packages in the eco system.

SublimeLinter tries to be a lean wrapper around linters to make them work from within Sublime Text and then provide a unified UI. If the linter doesn't offer anything smart to find its configuration, and Sublime Text doesn't offer a way configure something, we probably don't want to step in and provide a solution. It's going to be both a corner case and a huge amount of work because there is no plumbing for us to lean on, plus we will have to find a way for it to work with ST's config merging system without breaking it.

Member

braver commented Jul 30, 2018

Linters like eslint that have config files, will search "up" from the current file to look for their project's root and configuration. In most cases using the linter's native configuration enables this behaviour without you having to specify anything in SublimeLinter.

We lean on Sublime Text's API's for merging different levels of configuration, ensuring that it just works everywhere and works just like all other packages in the eco system.

SublimeLinter tries to be a lean wrapper around linters to make them work from within Sublime Text and then provide a unified UI. If the linter doesn't offer anything smart to find its configuration, and Sublime Text doesn't offer a way configure something, we probably don't want to step in and provide a solution. It's going to be both a corner case and a huge amount of work because there is no plumbing for us to lean on, plus we will have to find a way for it to work with ST's config merging system without breaking it.

@kaste

This comment has been minimized.

Show comment
Hide comment
@kaste

kaste Aug 3, 2018

Contributor

We currently don't have a super strong vision for big repos/monorepos etc. Instead of a proposed solution (folder settings) we first need a better understanding of the problem.

What we have today: In Sublime projects, you can open/reference multiple folders. The SL context variable $folder will point/expand to the first matching folder for a particular file. E.g. in a project file

  "folders": [
    {"path": "./bar"},
    {"path": "./foo"},
    {"path": "."},
  ],
  "settings": {
    "SublimeLinter.linters.somelinter.args": ["--config", "$folder/.somelinterrc"],
    "SublimeLinter.linters.somelinter.working_dir": "$folder"
  }

Now, SublimeLinter will set the working_dir to "./bar" if you edit "./bar/myfile.js", and use "./foo" for e.g. "./foo/otherfile.js". Likewise, it will use different config files.

FWIW as always.

Contributor

kaste commented Aug 3, 2018

We currently don't have a super strong vision for big repos/monorepos etc. Instead of a proposed solution (folder settings) we first need a better understanding of the problem.

What we have today: In Sublime projects, you can open/reference multiple folders. The SL context variable $folder will point/expand to the first matching folder for a particular file. E.g. in a project file

  "folders": [
    {"path": "./bar"},
    {"path": "./foo"},
    {"path": "."},
  ],
  "settings": {
    "SublimeLinter.linters.somelinter.args": ["--config", "$folder/.somelinterrc"],
    "SublimeLinter.linters.somelinter.working_dir": "$folder"
  }

Now, SublimeLinter will set the working_dir to "./bar" if you edit "./bar/myfile.js", and use "./foo" for e.g. "./foo/otherfile.js". Likewise, it will use different config files.

FWIW as always.

@kaste kaste removed the wontfix label Aug 3, 2018

@mathroc

This comment has been minimized.

Show comment
Hide comment
@mathroc

mathroc Aug 3, 2018

@kaste thankx that's good to know, might be enough in some situation (but doesn't help in mine because the relative path is not always the same)

fwiw, a solution with settings per folder would be fix my problem

not sure if that could be integrated more easily in SublimeLinter though, if not, feel free to close this issue

mathroc commented Aug 3, 2018

@kaste thankx that's good to know, might be enough in some situation (but doesn't help in mine because the relative path is not always the same)

fwiw, a solution with settings per folder would be fix my problem

not sure if that could be integrated more easily in SublimeLinter though, if not, feel free to close this issue

@no-response no-response bot removed the awaiting response label Aug 3, 2018

@braver

This comment has been minimized.

Show comment
Hide comment
@braver

braver Aug 3, 2018

Member

I think ideally the SL config is about your preferences and should be applied globally. E.g. you like to ignore some warnings. Linters should have their own configurations, you should be able to spread that over the file system and let the linter figure out what config to read.
As it is though, this model doesn’t work for many projects. Usually because the linter comes up short, e.g. it doesn’t provide a way to set certain config with a config file and we have to construct args. Or because we don’t always work on modern and up-to-date code bases. So SL steps in to help you be productive anyway.

This idea of the monorepo also isn’t something the open source community, particularly for JS and Python, which is where most of these linters come from, is used to. I think Eslint and Tslint work well in that environment, perhaps because they have serious companies contributing to them (with Facebook and Google being on the monorepo bandwagon), perhaps because they have more users than the other linters combined. For most tooling though, monorepos aren’t even considered (again, which is why FB and Google are making their own tooling to deal with them).

A monorepo with a weak linter, in Sublime Text, is basically a worst case scenario. I’m not sure SL can fix it if the entire structure doesn’t understand monorepos. It’s also not just a linter issue, it applies to build systems etc. as well.

Member

braver commented Aug 3, 2018

I think ideally the SL config is about your preferences and should be applied globally. E.g. you like to ignore some warnings. Linters should have their own configurations, you should be able to spread that over the file system and let the linter figure out what config to read.
As it is though, this model doesn’t work for many projects. Usually because the linter comes up short, e.g. it doesn’t provide a way to set certain config with a config file and we have to construct args. Or because we don’t always work on modern and up-to-date code bases. So SL steps in to help you be productive anyway.

This idea of the monorepo also isn’t something the open source community, particularly for JS and Python, which is where most of these linters come from, is used to. I think Eslint and Tslint work well in that environment, perhaps because they have serious companies contributing to them (with Facebook and Google being on the monorepo bandwagon), perhaps because they have more users than the other linters combined. For most tooling though, monorepos aren’t even considered (again, which is why FB and Google are making their own tooling to deal with them).

A monorepo with a weak linter, in Sublime Text, is basically a worst case scenario. I’m not sure SL can fix it if the entire structure doesn’t understand monorepos. It’s also not just a linter issue, it applies to build systems etc. as well.

@braver braver added the discussion label Aug 3, 2018

@braver braver changed the title from [feature request] per folder linter settings to per folder linter settings Aug 3, 2018

@kaste

This comment has been minimized.

Show comment
Hide comment
@kaste

kaste Aug 21, 2018

Contributor

So, this is relatively cheap to implement within the current system.

The only problem is, that we cannot search everywhere for such a '.sublimelinterrc' file, so the constraint would be that we only search for such files in the folders listed in the project file.

Of course, some upvotes, more user stories would help bring the issue forward.

Contributor

kaste commented Aug 21, 2018

So, this is relatively cheap to implement within the current system.

The only problem is, that we cannot search everywhere for such a '.sublimelinterrc' file, so the constraint would be that we only search for such files in the folders listed in the project file.

Of course, some upvotes, more user stories would help bring the issue forward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment