npm package contains minified files

Is your feature request related to a problem? Please describe.

The package as it is published on npm currently contains multiple minified files; this is problematic from a security auditing perspective, as minified code is difficult to audit. This is particularly problematic because of the often security-sensitive nature of the uuid module.

A more detailed explanation of the problem with minified builds and why they are unnecessary to publish in the first place, can be found here.

Describe the solution you’d like

Removing all minified builds from the npm package in a future release, instead either a) providing instructions for users on how to obtain a minified build, or b) if necessary for certain CDNs, publishing the minified builds in a separate package that users wouldn’t install into their project.

Describe alternatives you’ve considered

• Reproducing from source: Requires auditing the entire build stack due to potential supply chain attacks, with build tools being able to modify the code going through them.
• Prettifying minified code and auditing that: Cumbersome, unreliable because a lack of meaningful names makes it hard to understand the code correctly.
• Just not using the minified files: For a reliable dependency audit, all files present in the dependency tree must be audited, because there is (AFAIK) no runtime-level mechanism to block certain files from being loaded in eg. a multi-stage attack.

Additional context

N/A

[ctavan]

Wow, that thread escalated quickly 😂

While I would love to ease our pain as maintainers of this package, I think the uuid package has a long tradition of providing a good deal of backwards compatibility and I think this has actually helped keep the amount of noise on this repo relatively low since it mostly just works for most people…

I’d be afraid that restricting ourselves to only ESM would actually cause a lot of pain in the community, even if that may be the most modern solution at the moment.

So when we look at the support matrix right now we have:

	CommonJS	ESM
NodeJs	+	+
Browser	-	+

In practice the discussions have recently gone even in the opposite direction of considering to add a browser CommonJS build, see https://github.com/uuidjs/uuid/pull/616#issuecomment-1036638542 (<- that comment contains 4 more references where folks have been requesting this).

I’m still convinced that adding a CommonJS browser build would be fundamentally wrong at this point in time. But I equally think that it’s not realistic to get rid of the CommonJS Node build.

BTW to elaborate a bit on the export section in: https://github.com/uuidjs/uuid/blob/3a033f6bab6bb3780ece6d645b902548043280bc/package.json#L21-L29

• node.module is a pure Node.js ESM build which only gets chosen when people create bundles for node.js (e.g. with webpack or rollup). Yes, apparently people do that for serverless environments 🤷‍♂️ .
• node.require gets loaded when you require('uuid') in Node.js
• node.import gets loaded when you import 'uuid' in Node.js and this is actually a wrapper around the CommonJS module. This is a mitigation to the dual package hazard to ensure that only one instance of UUID gets instantiated even if in your dependency tree some modules are importing and some are require()ing uuid.
• default is a browser ESM build that gets picked up by bundlers when building for the browser (we use ESM here to support proper tree shaking).

Sometimes people manage to misconfigure their bundlers so that the bundler is looking for a CommonJS build which we don’t provide. I think this is always the wrong thing to do when using a bundler.

[ctavan]

Thanks for chiming in @ljharb!

To be clear, the only way a wrapping approach is viable for any package is if everything is in CJS, with maybe a thin ESM wrapper around it.

Yes, that’s what we’re doing here for Node.js!

If the desire is to avoid a build process while not excluding the majority of the ecosystem (for evidence of this, look at any popular package that’s gone ESM-only, and see how tiny a percentage of its users uses those versions), authoring in CJS directly is the only way to do that.

Agree! But since we want to provide an independent build that also makes sense for browser bundlers, ESM does have advantages for those environments (even if webpack managed to treeshake the CommonJS version of this module as well). I’m fine with keeping a build step, now that we have it.

@ctavan the only tweak to your exports field is that if you want to also have your package work in node v13.0-13.6, you’d make the dot object be an array of “object” and “default filepath string”.

I was considering that back when I introduced pkg.exports but decided against supporting these intermediate non-LTS Node.js versions. When they were still current, a few folks were complaining, but “upgrade to the next LTS release” was a viable solution for all of them, it was usually just an oversight that they were still on a 13.x version.