--yardopts not supported by the server command

[noraj]

The --yardopts can be use with the doc command to use a yard options file with a non default filename. This flag does not work with the server command, so only .yardopts can be read.

$ bundle exec yard doc --yardopts .yardopts-dev
$ bundle exec yard server --reload

Steps to reproduce

$ bundle exec yard server --reload --yardopts .yardopts-dev

yardopts is read

Actual Output

N/A

Expected Output

N/A

Environment details:

N/A

I have read the Contributing Guide.

[lsegal]

Customizing the .yardopts filename is not supported by the server components in YARD. It could work for the case of serving a single directory, but it would yield unexpected results if you were serving multiple directories (via -m or --gems) with some projects not using the options filename specified via command line-- in short you would have to know the project structure of all directories being served, which is very unlikely for --gems and fairly unlikely for most multi-library doc serving use cases.

[noraj]

I guess people using --gems will stick to using the default .yardopts and using --yardopts could be handy for single directory during development. Eg. .yardopts for production and .yardopts-dev for dev where --protected and --private added so you want to run yard server --reload --yardopts .yardopts-dev during local development and just using the default .yardopts for prod.

[lsegal]

The problem is that yard server --gems --yardopts .x, yard server -m --yardopts .x, or yard server -G --yardopts .x will yield unexpected results and cause confusion. That's 3/4 use cases where providing both options does not do what you expect, so it would likely need to be disabled 75% of the time. Rather than implement a feature that will be disabled 75% of the time, you can consider other workarounds if the use case is specifically for development.

One thing you could do is create a .yard-dev subdirectory and put a .yardopts file in there (.yard-dev/.yardopts) which references files one directory up, e.g. ../lib/**/*.rb. This pattern would allow you to create custom doc generation sets for different contexts.

[noraj]

One thing you could do is create a .yard-dev subdirectory and put a .yardopts file in there (.yard-dev/.yardopts) which references files one directory up, e.g. ../lib/**/*.rb. This pattern would allow you to create custom doc generation sets for different contexts.

It would requires to cd all the times, to create a sub-folder per custom yardopts and to prefix all files with ../. That seems like a quite nonviable workaround.

The problem is that yard server --gems --yardopts .x, yard server -m --yardopts .x, or yard server -G --yardopts .x will yield unexpected results and cause confusion. That's 3/4 use cases where providing both options does not do what you expect, so it would likely need to be disabled 75% of the time. Rather than implement a feature that will be disabled 75% of the time, you can consider other workarounds if the use case is specifically for development.

So --yardopts and -G, --gems , -m should be mutually exclusive options. Or it they can be both used and if the custom yardopts file provided via --yardopts is not found .yardopts can act as a fallback.