Docusaurus CLI throws when no subcommand is provided and when not using conventional config name

[xobotyi]

Have you read the Contributing Guidelines on issues?

• I have read the Contributing Guidelines on issues.

Prerequisites

• I'm using the latest version of Docusaurus.
• I have tried the npm run clear or yarn clear command.
• I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
• I have tried creating a repro with https://new.docusaurus.io.
• I have read the console error message carefully (if applicable).

Description

Attemt to specify custom location for docusaurus config fails with same error as if flag not provided at all, in fact, docusaurus seems not to take any flags at all, as --help flag (dont know if it exists at all) dont take any effect as well.

Reproducible demo

No response

Steps to reproduce

1. define relative config path as --config <path>
2. get an error that config not found

Expected behavior

--config flag takes effect

Actual behavior

Config file not read from specified path, though it exists

> ls ./.docusaurus/docusaurus.config.ts

Directory: ....\.docusaurus

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---          17.12.2023    23:27            811 docusaurus.config.ts

> yarn docusaurus --config ./.docusaurus/docusaurus.config.ts
yarn run v1.22.21
$ ....\node_modules\.bin\docusaurus --config ./.docusaurus/docusaurus.config.ts
[ERROR] No config file found.
[INFO] Expected one of:
- docusaurus.config.ts
- docusaurus.config.mts
- docusaurus.config.cts
- docusaurus.config.js
- docusaurus.config.mjs
- docusaurus.config.cjs
You can provide a custom config path with the `--config` option.
....\node_modules\@docusaurus\core\lib\server\config.js:24
throw new Error();
^

Error
at findConfig (....\node_modules\@docusaurus\core\lib\server\config.js:24:15)
at async loadSiteConfig (....\node_modules\@docusaurus\core\lib\server\config.js:31:11)
at async loadContext (....\node_modules\@docusaurus\core\lib\server\index.js:31:63)
at async externalCommand (....\node_modules\@docusaurus\core\lib\commands\external.js:16:21)
at async file:///..../node_modules/@docusaurus/core/bin/docusaurus.mjs:241:3

Node.js v20.10.0
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Your environment

• Docusaurus version used: 3.0.1
• Environment name and version (e.g. Chrome 89, Node.js 16.4): Nodejs v20.10.0
• Operating system and version (e.g. Ubuntu 20.04.2 LTS): Windows 11

Self-service

• I'd be willing to fix this bug myself.

[slorber]

yarn docusaurus does not take a --config option. You need to use a subcommand like start/build.

--help and --version do work without subcommands, if that's not the case please show us the proof because I can see them working locally.

[slorber]

Hmm you are right something doesn't work, but it's not the --config option (which requires a subcommand).

You need to have a known config file to be able to run docusaurus, docusaurus --help or docusaurus --version, otherwise it throws.

Can be reproduced on a newly initialized site:

[xobotyi]

Okay, i see, so it does distinguish subcommand and commnd flags
docusaurus --config .\.docusaurus\docusaurus.config.ts start != docusaurus start --config .\.docusaurus\docusaurus.config.ts

Which is kind of sad, since config path have to be repeated in each command without an option to make an alias script that will defined config location for all other commands

[Josh-Cena]

Will look at it myself today or tomorrow. After Dec 21 if there's still no news, others can take it up

[Josh-Cena]

This looks related to #8903: when the current command does not look like an internal command (where "internal" means process.argv.slice(2)[0] is not a command we recognize), we immediately let 3rd party plugins extend the CLI so their registered handlers may be able to handle the command. But to load 3rd party plugins, we need a site config, so we are in a deadlock situation (plugins need site config, but to parse the --config argument we need to load the plugins). What we want is a way to read --config before we even initialize plugins.

@slorber Do you think we should solve #8903 (which would automatically solve this), or do you think we should just check if a subcommand exists and special-case when it doesn't?