Unnecessarily large install size

[jaydenseric]

There are redundant files being published that significantly bloat the install size, which is currently 508 kB:

• https://packagephobia.now.sh/[email protected]
• https://unpkg.com/browse/[email protected]/

This is a shame because the actual code is quite elegant at ~5 kB:

https://unpkg.com/browse/[email protected]/index.js

Notably the 356 kB yarn.lock file should not be published.

It is best practice to whitelist exactly what should be published via a package.json files field, instead of using a blacklist via .npmignore:

https://github.com/jcoreio/promisify-child-process/blob/v3.1.4/.npmignore

Another opportunity to reduce the install size a bit is to remove dev tool config from the package.json out into separate config files, which will not be published due to the
package.json files field whitelist.

A little more tricky, but it would be nice to get rid of the Babel runtime dependency, as it appears to only be used for the CJS interopRequireDefault helper yet it pulls in the regenerator-runtime dependency:

https://unpkg.com/browse/[email protected]/index.js

I suggest refactoring the source to CJS, and using an ESM wrapper with a package.json exports field with conditional exports:

https://nodejs.org/api/esm.html#esm_approach_1_use_an_es_module_wrapper

Then you won't need Babel, and Node.js ESM will be supported whilst avoiding the dual package hazard.

[jedwards1211]

Actually the intent of @babel/runtime was to make things like Promise work in old environments, though I failed to realize that requires opt-in. But I'm pretty sure that's no longer necessary for LTS Node.

Wasn't aware that yarn ignores lockfiles in deps, thanks for letting me know.

I'll get working on this...

Know of any tools to autogenerate the ESM wrappers for larger projects that export multiple modules?

[jaydenseric]

Know of any tools to autogenerate the ESM wrappers for larger projects that export multiple modules?

Setting it up manually is probably your best bet. Here is an exports field example from one of my more complicated projects:

https://github.com/jaydenseric/graphql-react/blob/v11.0.0/package.json#L35

Note that I expose directories instead of individual files (except for index files, which are manually specified for dual ESM/CJS support and automatic resolution), e.g. "./universal/": "./universal/".

[jedwards1211]

@jaydenseric yeah, but the only way I'm able to get half as much done as I want to is to automate everything as much as possible 😅 I clone all my repos from skeleton projects with canned build config, use semantic-release on everything, and made a tool for bootstrapping from the skeleton projects, creating the package on GitHub and setting up CircleCI for semantic-release as fast as possible... so I'm hoping I can find a way to modernize my skeletons for dual packages.

[jedwards1211]

🎉 This issue has been resolved in version 4.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[jaydenseric]

It appears that @babel/runtime is an unnecessary dependency in v4?

[jedwards1211]

Oh hah 🤣 I removed the babel plugin, forgot to remove that

[jedwards1211]

🎉 This issue has been resolved in version 4.0.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀