docs: add CLI options to readme

[mmkal]

Related to #87

I didn't know there was a --base CLI option (I should have tried --help, but I assumed there were no options from looking at the readme), this just reformats the --help output as a markdown table.

[eslint-github-bot[bot]]

Hi @mmkal!, thanks for the Pull Request

The pull request title isn't properly formatted. We ask that you update the pull request title to match this format, as we use it to generate changelogs and automate releases.

• The commit message tag wasn't recognized. Did you mean "docs", "fix", or "feat"?
• There should be a space following the initial tag and colon, for example 'feat: Message'.
• The first letter of the tag should be in lowercase

To Fix: You can fix this problem by clicking 'Edit' next to the pull request title at the top of this page.

Read more about contributing to ESLint here

[voxpelli]

Looks good 👍

I wonder if it would be overkill to automate the README update, to ensure it stays in sync with any changes made to the CLI.

But that should be a follow up PR then, let's not block this on that 💪

[mmkal]

I actually maintain eslint-plugin-codegen and I'm planning on adding a preset that parses a CLI output to do this, so if that might be of interest I can test it out here as a PR when it's ready. If it seems like overkill you can just close, but it should be easy: the idea is you leave a markdown comment and if it ever goes out of sync it'll show up in CI as a (fixable) eslint error.

[antfu]

I personally don't really like to duplicate things, so we need to maintain and keep them in sync. Maybe we could instead mention that "Run npx @eslint/config-inspector build -h to see all the CLI options available"?

[mmkal]

I can update it to that. Though I do think it's a little less helpful for users since they then need to actually install the CLI to understand what it can do - they can't see from their phone etc.

If I make that change for now, would you be open to a future PR which keeps it in sync via eslint (no extra build step or anything)?

[antfu]

they can't see from their phone etc.

But why would someone need to view the option on their phone? If one really needs to, on the phone, they can use the phone to view the source code to see the listed option as well - either way they can't run it.

a future PR which keeps it in sync

That's the part I am not sure. "Keep in sync" for this kind of duplicate data doesn't create much value but introduces much maintenance complexity. For docs, I would like them to offer more insights/guidance than simply list the options, where the CLI already does.

[voxpelli]

But why would someone need to view the option on their phone? If one really needs to, on the phone, they can use the phone to view the source code to see the listed option as well - either way they can't run it.

When answering a question from someone else :)

I like things like https://unifiedjs.com/explore/package/remark-usage/

[mmkal]

Ok, no problem, I'll update this.

But why would someone need to view the option on their phone?

I sometimes come across this kind of thing on X and try to figure out if it's going to fit my use case. But it's not the majority use case for sure.

"Keep in sync" for this kind of duplicate data doesn't create much value but introduces much maintenance complexity.

I'm hopeful that the complexity can be contained in my plugin, and not add to the maintenance burden of this project. I might try it out since I'd like to build this feature anyway. No hard feelings if you decide to close when you see it!