Skip to content
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

Selene should search for configuration files that begin with a dot #469

Open
tomodachi94 opened this issue Dec 8, 2022 · 12 comments · May be fixed by #591
Open

Selene should search for configuration files that begin with a dot #469

tomodachi94 opened this issue Dec 8, 2022 · 12 comments · May be fixed by #591
Labels
A-bin Area: selene, the program C-enhancement Category: Feature request or improvement

Comments

@tomodachi94
Copy link
Contributor

Selene should allow prefixing all of its configuration with a dot. StyLua allows this.

This would aid with having developer tooling configurations being distinguished from ordinary source files.

@tomodachi94
Copy link
Contributor Author

tomodachi94 commented Dec 8, 2022

For example, I would have a file, .selene.toml, that contains the same things as selene.toml. In addition, I would have a .my-custom-stdlib.yaml file that contains my custom standard library. In my selene.toml, I would source it as my-custom-stdlib.

@tomodachi94
Copy link
Contributor Author

tomodachi94 commented Dec 8, 2022

Workaround: Specify the --config option when running selene, and prefix your std with a dot.

@Kampfkarren
Copy link
Owner

.selene.toml seems fine, but I think standard libraries should just work with putting the dot in the std name itself, we already have a bunch of weird combinatorics with them

@Kampfkarren Kampfkarren added C-enhancement Category: Feature request or improvement A-bin Area: selene, the program labels Dec 17, 2022
@Zeioth
Copy link

Zeioth commented Mar 7, 2024

This is a convention of most formaters/linters. It would be very desireable.

@chriscerie
Copy link
Collaborator

Is there a stronger motivation for this? Introducing multiple ways to do the same thing is not great, and eslint is moving away from such behavior.

@LastTalon
Copy link
Contributor

eslint is moving away from such behavior.

ESLint is moving away from their old config format entirely. It's not really about prefixing with a ., which is usually just to treat the config as a hidden file.

@chriscerie
Copy link
Collaborator

eslint is moving away from such behavior.

ESLint is moving away from their old config format entirely. It's not really about prefixing with a ., which is usually just to treat the config as a hidden file.

I more meant there doesn’t seem to be a strong enough use case for eslint to support dot-prefixed configs in their new system. What’s different about lua where this would be worth a more complicated config resolution?

@chriscerie
Copy link
Collaborator

I'm going to close this for now as I don't see the benefits worth the added complexity. I'm not entirely opposed to reopening this in the future if there's a stronger motivation.

@chriscerie chriscerie closed this as not planned Won't fix, can't repro, duplicate, stale Mar 23, 2024
@Zeioth
Copy link

Zeioth commented Mar 23, 2024

chriscerie as already mentioned, it is a strong convention for all linters across all operative systems.

You can check out other tools.

@Zeioth
Copy link

Zeioth commented Mar 23, 2024

In case you are not familiar, on UNIX system (Linux, MacOS, and others), adding a dot in front of the file, make the file hidden for file browsers. That way we avoid polluting our user projects.

@LastTalon
Copy link
Contributor

What’s different about lua where this would be worth a more complicated config resolution?

Right, as stated it has nothing to do with Lua and entirely to do with supporting filesystems that expect prefixing with a dot to hide files. This can easily be asked of any tooling that uses the file system. I can't find any documentation one way or the other with regard to eslint because, again, this is a new file name with an entirely new format and that coincidentally is removing the dot prefixing the old name. If they don't have plans for this with their new format I would fully expect issues to show up very quickly for it for the same reason, just as you find issues of the same nature for virtually every tool.

The better question is what makes selene unique to other tools in not wanting/needing to support hidden files on unix filesystems?

@chriscerie
Copy link
Collaborator

Thanks. When we see a mainstream tool move away from a convention it's natural to question why and it's better to document such considerations now than later.

@chriscerie chriscerie reopened this Mar 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-bin Area: selene, the program C-enhancement Category: Feature request or improvement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants