module: add --experimental-strip-private-modules

[marco-ippolito]

Followup of #63853
Adds a flag to allow type stripping inside node_modules ONLY if private.
I think I covered #63853 (comment) concerns about smuggling private package.json's in a non private package

[nodejs-github-bot]

Review requested:

• @nodejs/config
• @nodejs/loaders
• @nodejs/typescript

[aduh95]

We'd need to document private in https://nodejs.org/api/packages.html#nodejs-packagejson-field-definitions

[marco-ippolito]

Adding the blocked label to make sure @nodejs/typescript reviews and agrees with this change

[mcollina]

lgtm

[aduh95]

I don't think it's worth it, also I don't think that we can use private to reliably guess if a package was downloaded from a registry or not, and it adds arguably a lot of complexity (in comparison for e.g. adding a loader, or not putting the code inside node_modules)

[RyanCavanaugh]

Weighing in from the TypeScript team: We're OK with this, and don't have any concerns about this eventually going unflagged either.

That said, we wanted to re-emphasize @ljharb's and others' comments in the prior PR thread. Our top priority in this space remains ensuring that un-compiled .ts is never the entry point for a package in the public registry. The fundamental technical motivations behind that haven't changed, and we don't see any path forward where they could change.

Keeping this restricted to private: true is a great compromise that enables that goal while still making monorepo dev/deploy more straightforward, we just want to have absolute clarity and consensus that this is not a stepping stone to enable type stripping of public registry packages.

[marco-ippolito]

we just want to have absolute clarity and consensus that this is not a stepping stone to enable type stripping of public registry packages.

To be explicit for @nodejs/typescript: this is not a stepping stone to public-registry TS.
I have it documented as a non goal
https://github.com/nodejs/node/pull/63869/changes#diff-7349c17bce4d97526eefcb6f8291d617e7edb92ed9927fd3b9264e8014fc4e7cR1423

@aduh95 I kindly ask you to reconsider.
The design relies on the contract that registries refuse to publish a "private": true root.
Im sure there are a million ways to work around that, but for the vast majority of people it doesn't matter.
And just like people didnt want to run TypeScript through an external loader, they want a built-in solution.
The real complexity today is in the hoops people have to go through to bypass this limitation that you mentioned here: #63853 (comment)
This PR is small and self-contained in comparison, and it removes that burden.
I also think this opens the door to experimenting in ways that were harder before.