npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

rebundled

v0.0.0

Published

A tool which rebundles other people's npm packages so more people can use them

Downloads

3

Readme

rebundled

A tool which rebundles other people's npm packages so more people can use them

What?

This package automates the steps required to take an npm package associated with a GitHub repo, and publish it under the @rebundled/ npm organization, with some tweaks to the package.json file and/or the build process.

Which?

The packages that are currently rebundled are those in package.json's dependencies (mostly so renovate can try to keep them up to date). At time of writing, these are:

  • postgrest-js: because I opened a pull request to improve the types and got impatient waiting for it to be reviewed
  • p-memoize: because it was switched to ESM meaning I couldn't use it in a work project that was still on CommonJS.
  • truncate-json: ditto

Why?

Originally, this project started as a workaround for some open source libraries, which dropped CommonJS/require support and switched their outputs to pure ESM - see this gist for an explainer. Now, it's also used to publish versions of packages based on forks of OSS projects which take a while to get attention.

However, in lots of real world projects, switching over to ESM is messy, and sometimes not possible. Tools can conflict with each other, and updating thousands of imports to work the right way, for modern ESM-only libraries and legacy require-only libraries - which may include making some imports async, in synchronous contexts, adding file extensions to relative imports and various createRequire tricks, and then configuring tsc, eslint, swc, ts-node, ts-jest to work across all of them - simply isn't practical. Developers want to be able to install packages and have them "just work". On the other hand, some maintainers are unwilling to support multiple import styles.

Luckily, microbundle exists. So, what this repo does is take an existing package, make some small adjustments to its package.json, run microbundle, on it, and publish it as a separate package under the @rebundled/ npm organization.

Why microbundle?

Some aggressive-ESM packages have other aggressive-ESM packages as dependencies, meaning just using tsc isn't good enough. microbundle is a bit of a sledgehammer approach to make sure the rebundled packages are usable. tsup might be another option - this repo is not tied to microbundle, but it happens to use it for most of the packages.

What about patch-package?

patch-package is great, but has some limitations. First, the work needs to be done by the end user. With rebundled, the alterations are done once and the rebundled package can be installed by any number of people without having to worry about what to patch and how. Second, patch-package is only really designed for hard-coded changes to code. rebundled allows modify the whole build step, in a repeatable way.

How are packages versioned?

This repo installs the rebundled packages as regular dependencies, and will rely on renovate to regularly updade them. There's a CLI which allows passing in a --version, or setting it to --bump the existing version. There's also a --prerelease CLI arg allowing publishing with the specified tag.

Eventually, a github action running against the main branch will automatically publish equivalent versions of the originals within a few days of them being published. Note: at time of writing this GitHub action isn't set up yet

What next?

Right now rebundled isn't written to be used outside of this repo. But eventually, it could be. With some additional configurability it could allow rebundling other dependencies than the handful that are hardcoded here now.

What are the downsides?

  • Maybe: the dual package hazard. microbundle outputs two separate versions for each import style. possibly
  • Splintering the OSS community. It's confusing to have alternate versions of packages. However I think this method is less harmful than using manually-maintained forks since the changes to the packages are programmatic.