Consider doing this instead (also in drive.dart):

final HttpsConfig? httpsConfig = (fileConfig.https ?? HttpsConfig()).copyWith(
  certPath: stringArg('web-tls-cert-path'),
  certKeyPath: stringArg('web-tls-cert-key-path'),
);

Thanks for the suggestion @bkonyi!

I tried implementing it, but HttpsConfig() cannot be instantiated without arguments since both certPath and certKeyPath are required parameters in the constructor:

const HttpsConfig({required this.certPath, required this.certKeyPath});

Instead, I've simplified the code using HttpsConfig.parse() which handles all the cases cleanly:

final HttpsConfig? httpsConfig = HttpsConfig.parse(
stringArg('web-tls-cert-path') ?? fileConfig.https?.certPath,
stringArg('web-tls-cert-key-path') ?? fileConfig.https?.certKeyPath,
);

This achieves the same simplification (reduced from 15 lines to 4 lines) while:

• CLI args take precedence over file config
• Falls back to file config values when CLI args not provided
• Returns null if neither provides both values
• Throws ArgumentError if only one path is provided (existing behavior)

I've also added tests for CLI precedence as requested. Let me know if you'd like any changes!

@Saqib198 – I moved things into this shared function so we have fewer places to keep this logic up-to-date!

Yeah, these should all be changed, too – right? @Saqib198

RE comments from @mdebbar

I believe the way they are now is correct. But the issue says web-port's and web-hostname's precedence is incorrect, which is confusing.

Ah!

I get it.

By putting headers after this.headers, it overwrites.

But with port and host, the ?? has things the other way.

So it reads weird, but I think the code as it is now is correct.

But I agree, I see no code changes for anything but headers.

So was it really broken? Or are we missing something?

Thanks for calling this out — happy to clarify.

You’re right that web-port and web-hostname already had correct CLI > file precedence.
They use the pattern:

host: host ?? this.host,
port: port ?? this.port,

where host / port come from the CLI layer, so CLI values correctly override
web_dev_config.yaml today.

The regression introduced in 3.38 specifically affected:
• headers (due to merge order: {...?headers, ...this.headers})
• HTTPS config (due to conditional logic that ignored CLI TLS args when file config
was present or missing)

That’s why this PR only changes:
• header merge order
• HTTPS config resolution

The issue description mentioned web-port / web-hostname because the symptom users
observed was “CLI args ignored”, but the actual root cause was headers + HTTPS.
Port/hostname were already behaving correctly, so no change was needed there.

Happy to update the PR description or issue wording if that helps reduce confusion.

Ok, that makes more sense. Thanks for clarifying!

I would say yes let's update the issue and PR descriptions. If it confused me and @kevmoo, I'm sure it'll confuse more people later when they look at the history of this code.