,
16 tweets,
2 min read
Read on Twitter
Webpack desperately needs competition.
People are asking what I would want to see in a competitor. Basically, something focused on ingesting modules and code-splitting them.
You may say "that is webpack" but you would be wrong. You'd be wrong because I spent my entire Sunday getting something basic to work.
I wanted to add a module after the initial compilation pass, who contents was based on the results of the compilation. Nothing was working.
You see, the most basic functionality—importing JS modules—won't work if you miss FlagDependencyExportsPlugin and FlagDependencyUsagePlugin.
The only way to learn about this is to either read over every line of the codebase or step painstakingly through many async abstractions.
(If you're lucky, of course, and the thing you actually need to care about is not extracted to enhanced-resolve or loader-utils, etc.)
The core implementation of the most basic features is all made up of multiple "plugins."
How they interleave and share state is left as an exercise to the reader. It feels less like spaghetti code than… quantum entangled noodles.
Another issue is that the much-vaunted plugin hooks, to me, feel ad hoc—added as needed rather than via some rationalization.
Some plugins can be async while many others cannot. What happens if you need to do something async in a sync hook?
I just want something constrained that can take a directory of loose modules as input and outputs one or more code-split bundles.
And ideally the functionality would be obvious from a straight read-through, not emergent behavior from plugins congealing.
I've already belabored the point to @TheLarkInn IRL, but I think adopting TypeScript for the webpack internals would help *a lot*.
@TheLarkInn I'm excited to see the changes to the plugin API that make it more amenable to typing.
@TheLarkInn I hope the team continues to focus on paying down tech debt and refining internals.
