cli: remove --no-experimental-global-webcrypto flag

[panva]

Removes the --no-experimental-global-webcrypto flag and moves the global definitions to internal/bootstrap/browser.

[nodejs-github-bot]

Review requested:

• @nodejs/crypto
• @nodejs/startup

[panva]

@aduh95 what is the semverness of this change? We've only made the webcrypto api global (and stable) by default in 19.x onward.

Also, should process.config.variables.node_no_browser_globals continue to affect the globals within internal/bootstrap/browser?

[aduh95]

I'm not sure we should rush it, unless having the flag is blocking something else.

[aduh95]

Also, should process.config.variables.node_no_browser_globals continue to affect the globals within internal/bootstrap/browser?

Yes, as it simplifies the job of embedders such as Electron that expose browser globals from another runtime such as Chromium. It's being taken care of by

node/src/node_realm.cc

Lines 226 to 231 in 4310522

	if (!env_->no_browser_globals()) {
	result = ExecuteBootstrapper("internal/bootstrap/browser");
	if (result.IsEmpty()) {
	return MaybeLocal<Value>();
	}

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/48840/

[panva]

I'm not sure we should rush it, unless having the flag is blocking something else.

It's probably just blocking the TODO so that pre_execution could get cleaned up.

If that's not a pressing issue I propose we alias the flag as --no-global-webcrypto in 19.x and remove the unstable documentation around the flag instead.

WDYT?

[aduh95]

I think we need to keep the flag as experimental and get rid of it in the near future, if we remove the experimental part of it, we would have to go through a full deprecation cycle.

While the WebCrypto implementation itself is robust, and deserves to be called stable, the --eval and --print integration (that keeps globalThis.crypto as referring to WebCrypto but introduces a local crypto that refers to node:crypto) is much less so, and still quite new, I think we should leave an escape hatch for a little longer.

I would do that for 21.x or 22.x, so in case the current implementation breaks someone's code, they have a full LTS cycle to adapt and can use the flag to unblock them in the mean time.

[panva]

Very well. I did not think of the CLI flag itself as experimental. I'll revisit this before 21 or 22.