Support for a standardized ignore file

[SiriusStarr]

It'd be convenient to dump an ignore file at the root of your JD directory instead of having to specify ignored patterns via the CLI.

Ideas for the file:

• .jdignore
• .jdlintignore

[mh166]

I really like this idea. 😊 FWIW, I would prefer .jdlintignore because this narrows it down to the scope it's actually used in: for jdlint. You never know if JD himself will come up with a project or app at some point that could make use of a .jdignore file.

Another approach could be a .jdlint.conf file: this would allow us to put all arguments there which, otherwise, we would have to specify on the CLI each time.

[SiriusStarr]

Unless we start the .jdignore convention and make Johhny follow it... 😉

But no, that's probably advisable to avoid polluting the more general file name.

I have definitely pondered the idea of a config file of some kind as well; it would be nice to be able to just point this at a directory and have it go, especially if you have multiple directories with different options to lint (as things get more configurable).

The question there becomes, is it worth it to still split the ignores into their own file, as e.g. git/syncthing/etc do?

[mh166]

That's an interesting question, indeed. After giving it some thought, I think it's best to have to separate files for that.

While one file for all might look cleaner in ls -la, I think two files bring more benefits:

• Easier for users to edit: if they just care about adding ignore patterns, a simple file with one entry per line is quickly done, without having to worry about the correct syntax. Also, most people who will use a tool like this are probably already familiar with the .*ignore-file pattern.
• Easier for you to parse: if within the same config file, either the user has to do more work ("What is the correct format to put a list of ignore-patterns? YAML-, TOML-, JSON-, INI-, custom syntax?"). Or you have to do more work (e.g. writing your own parser for a custom config format to make it easy for people)
• Safer in terms of error handling (I guess?): an error in the config part still allows for proper loading of ignore-patterns. And vice-versa.
• Better future-proofing: should you ever have a need to evolve the config file, the ignore patterns can safely be ignored.

So TL;DR: two config files would be my favorite. Maybe .jdlintignore and .jdlintrc or something.

But that's just my two cents. 🙃

---

PS: Here are some mock-ups of possible config files. I like YAML the best, but I know not everybody might agree. 😄

Config file with YAML syntax

# jdlint.yaml

jdex: /home/user/Knowledge/00.00 📇 System Index
altzeros: true
json: true
disable:
  - NONEMPTY_INBOX
  - DUPLICATE_ID

Config file with TOML syntax

# jdlint.toml

jdex = "/home/user/Knowledge/00.00 📇 System Index"
altzeros = true
json = true
disable = ["NONEMPTY_INBOX", "DUPLICATE_ID"]

Config file with INI syntax

# jdlint.ini

[settings]
jdex = /home/user/Knowledge/00.00 📇 System Index
altzeros = true
json = true

[rules]
NONEMPTY_INBOX = true
DUPLICATE_ID = false

[mh166]

Oh, and another nice bonus just came to my mind:

More flexibility thanks to central config location

You might want to check multiple locations for a valid structure: like your local Documents folder, Dropbox, a synced drive, or even your NAS. You could just cd into whichever directory you want to check (say ~/Dropbox/), and jdlint could still pick up the config file from your home directory.

That should work nicely because your JDex probably stays in the same place, even if the folder you're checking changes.

Plus, different storage locations might need different ignore patterns. So here, too, it would come in handy to have two separate config files: a (maybe) central config file and an ignore-file local to each storage location.

[SiriusStarr]

I am inclined to agree with your analysis and personally prefer the separated ignore/config files too.

As far as a config file, I personally would prefer JSON, but most people won't, so TOML is probably the best pick here, as it doesn't introduce a dependency (unlike YAML), and I'm doing my best to keep this dependency-less, given the nightmare that Python package management is.

Config files do introduce the need to formally specify what takes precedence over what (and where we look). The root of the folder we point it at (i.e. the root of the decimal structure) is an obvious choice. ~/ or XDG_CONFIG_HOME get iffy inasmuch as Windows support becomes a huge shrug then. Current working directory makes me a little squinty, as there's not a clear sense of whether working directory or structure directory should take precedence. (I think it's sound for command line args to take precedence over config file?)

I'm leaning towards (in decreasing precedence):

1. CLI
2. Config file location specified via CLI arg
3. Root of decimal structure files
4. (Maybe?) Root of JDEX? Seems like it'd be nice to specify things here, but specifying non-jdex-specific things feels weird?