not fan of this kind of change 🤷‍♂️ I'd rather do the opposite and ensure all commands are never partial => handle edge cases and apply defaults at the edge of the system

The problem is that writeTranslations should not be seen as fully internal. It's exported from the main interface and users may import @docusaurus/core and use it as a programmatic API. Therefore, I'd keep maximum compatibility with the CLI interface.

Related: #4841 We should always assume the existence of those users that don't interact through the CLI. Even if it's technically not documented usage, I don't see why it makes the architecture any different if we apply defaults within docusuarus.mjs or writeTranslations.ts—as long as we only apply it once. NOT doing it in docusuarus.mjs means (a) more permissive programmatic API and (b) a CLI registry that's easier to maintain in the long term because it's not intertwined with the implementation, but only a very thin wrapper around each exported function.

ok, that seems reasonable

What I don't like is to have long methods receiving partial options, where there's always a risk to end up using the partial option on which default was not properly applied

Can we split the methods in 2, something like this?

function doWriteTranslations(siteDir: string, options: Options) {
	// actual code
} 

export function writeTranslations(siteDir: string, options: Partial<Options>) {
	return doWriteTranslations(siteDir, applyDefaults(options))
} 

Yes, makes sense.

where are these default values being applied now?

isn't it convenient that the default value and the doc message mentioning it are co-located?

Why not doing the opposite instead: always apply all default values in this file, ensuring we don't have to handle partial options anywhere else in the system?

These have always been applied internally, before and after. These default values actually only serve the purpose of being confusing & overly defensive.

as far as I understand this is the only place where 3000 is defined.

Otherwise it's the default of the underlying lib, which as you can see, can change over time (vercel/serve#680)

I'd rather keep applying these defaults explicitly so that we don't depend on underlying deps changes.

Also we can use the default options in commander help messages

  .option('-p, --port <port>', `use specified port (default: ${DefaultServeOptions.port})`)

Oh... you're sure? 😄

ah 😅 didn't search in utils