Speeding up the JavaScript ecosystem – The barrel file debacle

    if (process.env.NODE_ENV === "development") {
      module.exports = require("./another-file.dev.js")
    } else {
      module.exports = require("./another-file.js")  
    }

I tried to make this work for ESM too, but there were too many edgecases due to module namespace objects being observable (`import * as `)

A similar thing could be done for barrel files with `"sideEffects": false`. We don't currently follow nested default exports which makes this harder to do as effectively (we do support "sideEffects": false)

Instead of detailed analysis of the barrel files in a specific project+dependencies, there are vague exaggerated comparisons like "What's quicker? Having to load 30k files or just 10? Probably only loading 10 files is faster." Of course 10 modules is faster. But are there 29,990 barrel modules in Webpack?

Also, why is running esbuild+node faster than just node? Does that suggest the problem is not just lots of dusk reads, but something inefficient in the way node processes the module graph? Could that be improved?

Anyway this is an interesting direction of inquiry, and definitely worth considering!

• 0.15s ÷ 500 = 0.3ms

• 0.31s ÷ 1000 = 0.31ms

• 3.12s ÷ 10000 = 0.312ms

• 16.81s ÷ 25000 = 0.6724ms

• 48.44s ÷ 50000 = 0.9688ms

My own observation on a Surface Book six years ago was that in Node.js under Windows, each module had about 1ms of overhead when there was warm file system cache—that is, simply bundling with Rollup saved 1ms per file. If this sort of thing interests you, quite a lot of useful stuff came out of https://github.com/stylelint/stylelint/issues/2454 which I filed because I was unhappy with stylelint taking over a second to import. And that must have been only in the order of one or two thousand modules, when the behaviour is still close enough to linear.

However when exporting a public/published module it can become onerous to ask the user to import 7 files instead of 7 items from one module.

In a perfect world, this would not be much of an issue because tools would cache these resolutions/imports and their treeshaken code. In the current world, you could prepackage your project even on Node, so that there’s only one file to load, and no extra unused code.

However, the ecosystem tooling is a total piece of crap.

Just the other day I was trying to update eslint dependencies in monorepo only to have builds broken, tailwind stop working on next.js project. Then little tailwind prettier plugin fell off. Some things support ESM, others not yet.

I seriously hope that something like bun will become a one single tool to use. One tool that works with TS, supports linting, testing, tailwind, etc, etc, etc. One single fucking thing that works.

I'd rather use someone elses opinionated approach and never look at the configs again than waste 3 days trying to configure a single fucking eslint config for monorepo.

Now the barrel fucking files is the problem. What happened to cache? Like it's 2023. Can't we just load everything from cache?

import Button from "@cool-lib/core/button";

import Link from "@cool-lib/core/link";

import Widget from "@cool-lib/core/widget";

This is similar to what lodash does too. Still have more imports, but only one package.json dependency! And the same perf gains.

Direct paths also make file structure a part of api and that may not be the desired effect. In addition the bigger problem is not barrel files in your project but rather those in all third-party dependencies

Is that confirmed?

I've been following this issue:

https://github.com/jestjs/jest/issues/6957

And what Jest actually does is still kind of muddy.

In contrast to that, other test runners like AVA have a clear description what happens when:

https://github.com/avajs/ava/blob/main/docs/01-writing-tests...

How do you run your project where this happens? I thought everyone complied it separately and then ran it, not both at the same time. Shouldn't your tooling tell you immediately that it's the compilation being slow and not the code?

Personally I think the readability of having few import lines from shared barrels, compared to a forest of lines, are very useful.

> The term "barrel" is a metaphor. Just like a physical barrel holds multiple items in one container, a barrel file holds multiple exports in a single file, making it easier to manage and import.

https://chat.openai.com/share/93cb04ca-fd6f-46f0-991f-2d7f4c...