October 31, 2025
A little late, but here is the Q3 2025 community showcase! 🎉
The community have been producing some great things over the last few months, and improving even more projects. Here's just a few highlights of what we've been up to.
e18e GitHub Action
Recently, we saw the launch of the official e18e GitHub Action! This action allows you to easily check for dependency changes in your pull requests.
It applies various checks to determine if the dependency tree has changed in an unusual or notable way, helping to catch potential issues before they make it into your main branch.
Trust levels
The action detects when a dependency has changed its trust level. There are currently three trust levels:
- Trusted: Published using OIDC (trusted publishing) with provenance
- Provenance: Published with provenance, but not using OIDC
- None: No provenance or OIDC
With the rise in supply chain attacks, it is important to be aware of if a package changes between these trust levels. The action will do this by flagging any decrease in trust level for a dependency.
Install size
This check will flag any pull request which increases the install size of your package overall.
The install size of a package is that of the node_modules directory after running an npm install. Significant increases are often a sign of bloat or unnecessary dependencies being added.
Bundle size
There also exists the ability to check for bundle size changes. This differs from install size as it is the size of the npm pack result (i.e. the tarball which would be published to npm).
This is extremely useful for libraries, as it can help catch accidental increases in bundle size which would affect end users.
Module replacements
Of course, this also plugs into e18e's existing module replacements, allowing you to enforce the use of more performant alternatives to certain packages.
If a pull request introduces a dependency which the community have marked as having suggested replacements, it will be flagged by the action.
What's next for the action?
This action is still evolving, and we plan on adding more checks in the future. If you have any ideas or feedback, please open an issue.
Module replacements
As part of a wider effort to improve documentation of e18e recommendations, the community have been hard at work adding the new module replacements docs!
These new docs provide migration guides and tips for each of the recommended replacements, making it super easy to switch.
Just a few examples:
Big thanks to @outslept for doing the majority of the work on this!
modern-tar and nanotar
While investigating ways to reduce install size and complexity, a commonly raised issue has been the use of the tar package, or the tar-fs package.
tar comes in at 1.8MB with 6 packages, while tar-fs is 3.6MB with 17 packages.
Both of these packages are rather large, and the community have been itching to replace them with something more lightweight for a while now.
That's where modern-tar and nanotar come in!
nanotar
nanotar is a super tiny runtime-agnostic implementation of parsing and creating tar files.
It comes in at just 37KB and 0 dependencies!
This comes from the unjs ecosystem, which has many more lightweight packages like this. Thanks to @pi0 for this one!
modern-tar
While nanotar is great for parsing and creating tar files, it doesn't currently have a way to extract them to the filesystem.
That's where modern-tar comes in!
modern-tar is can pack and unpack tar files to and from the filesystem, while still being very lightweight.
Similarly, it comes in at only 76KB and 0 dependencies 🎉
Really awesome work by @ayuhito here!
Immer
Delving into the speed up category, we've seen some great improvements to the popular immer library recently.
@acemarke has been hard at work doing deep dives into the CPU and memory performance of immer across the board. He has made an impressive number of optimizations, and is still going!
You can read all about it on the latest GitHub issue, where he details many of the changes made so far. Just a few highlights:
- Improving iteration by avoiding
Reflectand caching object shapes - Rewriting finalization to be callback based instead of recursive
- Overriding array methods to avoid creating proxies on reads
- Avoiding object spreads for shallow copies
These optimizations have led to some impressive speed-ups. For example, the latest branch is 20% faster than main on many benchmarks!
We also recently held our first community call, where we were lucky enough to have @acemarke walk us through these improvements and show us more of the deeper investigation.
Really great work here! 🙏
Storybook
Storybook strikes again with another huge saving - migrating to ESM only!
They have announced Storybook v10 will be going ESM only. With this migration, they're able to drop all legacy CommonJS code from their published packages.
Storybook and many other popular packages currently ship two builds in their npm packages - one for CommonJS (CJS) and one for ESM. This means even if you install into an ESM-only project, you will still download the legacy CommonJS build, along with the duplicated type definitions.
By going ESM only, all of this falls away and there remains only one copy of everything.
This drops the storybook package from 66MB to 53MB, a great saving!
On top of this, even more savings were gained by resolving some tree-shaking issues. Big thanks to Bill for this one!
Netlify
Netlify have been collaborating with the e18e community for some time now, and putting great effort into improving the performance of their OSS packages.
Recently, we've seen two huge savings from them:
@netlify/edge-functionswent from 34MB to 8.4KB! (Release notes)@netlify/functionswent from 93MB to 40KB! (Release notes)
It's not often we get to see savings as crazy as these. The Netlify team have done an amazing job here.
Much of this saving comes from publishing two separate packages - one for development (with a bunch of dev-time tools, emulators, etc.), and one for production (just the runtime code).
This means production installs will run much faster, and the cost of the development tools is only paid when needed.
Upcoming projects
e18e CLI
The e18e CLI project missed a few milestones and isn't quite ready yet. However, with the completion and success of the GitHub Action, we're now in a much better place to complete the work.
This is core to the tooling the e18e community wants to provide, so we will be pushing hard to get this out soon!
Our vision for the CLI is that it can offer roughly the following:
- Dependency tree analysis matching that of the GitHub action
- Automated migrations to suggested replacements
- Publish linting
- Type definition linting
We are aiming to release an alpha version very soon, and will be reaching out to many of you to help test it out!
e18e MCP
We're also working on an e18e MCP server! This will allow us to offer module replacements as a data source to LLMs.
This is early stages but will hint to your chosen agent on which libraries to use and modern syntax to prefer.
The same capability should be available via the e18e CLI, leaving the choice of which you use up to you.
Module replacements v2
Finally, we're working on the next version of the module replacements data 🎉
One of the goals of this is to allow us to support more engines other than Node, and to offer syntax-only replacements (e.g. new platform capabilities).
Once this is complete, our tooling should be able to more intelligently suggest replacements based on your project's target environment. If you use Bun, for example, it will prefer built-in Bun APIs over third-party alternatives.
Package publishing guide
In the wake of the recent supply chain attacks, many community members have been asking how to best secure their package publishing process.
To help with this, we've put together a package publishing guide which goes over best practices for securely publishing your packages.
In this guide, we cover how to configure a typical OIDC setup with GitHub Actions, as well as some best practices around keeping the workflow secure. We've also published a few different "recipes" to show how you can do the same with various changelog/release management tools.
This is the result of many discussions in the community, so a big thanks to everyone who contributed! Particularly, thanks to @sxzz, @dominikg, and @jviide for their help putting this together.
Community calls / stream
We had a small trial of a community call when @acemarke presented his immer optimizations. This was a great success, so we plan on doing more of these in the future!
Nothing is set in stone yet, but we're planning on doing a monthly community call, usually with a guest speaker from the community. Hopefully, this will give some good insight into what people are working on, and will help teach us all new things.
Keep an eye out for announcements in our Discord when the next one is scheduled.
Working Draft podcast
The Working Draft podcast also recently had an e18e-focused episode! You can check it out on their website (Note it is in German language).
Great work by @fuzzyma and @thealexlichter for representing the community so well.
We're always happy to see community members getting involved in advocating for better practices around performance like this. If you run a similar podcast or want to suggest one for us to appear on, please let us know in the Discord!
ViteConf
Earlier this month, the first in person ViteConf was held!
A few of us went along, and we even had the first e18e talk there 🎉
This was a great experience and so many people were interested in what the community has been up to. We'd love to make this more of a regular occurrence to help share the knowledge and increase collaboration.
From this event alone, we've kicked off a few collaborations with Astro, Netlify, Nuxt, and more!
This was also the first time a few of us were in person together. Just a few of the amazing people in our community who made the trip: @antfu, @bluwy, @fuzzyma, @pi0 🥳
Get involved
If you'd like to help out, come join our discord and say Hi!