You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TL; DR: I will build a new esbuild-powered build tool, called "espub"
Brief history of nanobundle
nanobundle, as the name suggests, is a bundler. It aimed to provide effortless library building by adding some tweaks to esbuild's bundle mode. It's just like what microbundle does based on Rollup, that first inspired.
In v1, I focused on leveraging the full power of conditional exports in Node.js. And since TypeScript didn't support multiple entries at the time, this was a reasonable compromise. As a result, it was sufficient to support “small libraries” use cases and is compatible with the TypeScript ecosystem without noise.
Current status of nanobundle
I still use nanobundle actively in my daily work.
But at the same time, I see numerous cases where nanobundle is not a good fit because it is essentially a "bundler".
The bundler, by definition, removes the module semantics from the output after it has been performed. So I can't build things that depend on module semantics (I can approach it "cleverly", but it's overly complex or unpredictable)
While I was recognizing its limitations, I stopped exploring further features. And waiting for the ecosystem to move.
XState v5 is released. It supports a better concurrency model than before with first-class actor support.
So what's the plan?
I still have trouble finding build tools that work for me in many situations.
Type checking is performed independently. tsc/babel is too slow to transpile. Most tools still don't handle conditional exports correctly. And more importantly, I moved most of my projects to ESM-first. I don't want to "bundle" my lib codes anymore.
It seems like there is still a chance to build a perfect esbuild wrapper. So I will do that.
It will be rebranded under the name "espub" because it is no longer a "bundle"-first tool. It will still be able to bundle stuff, maybe I can keep the "nanobundle" as its alias.
ETA?
I'm definitely exploring in this Dec, but I can't promise anything.
I'm personally having productivity issues, and I also have other projects I'm involved with. Maybe you can make it faster than me.
I've actually seen a few close ones like tshy, pkgroll and bunchee. Unfortunately, none of them isn't for me. I don't expect someone to build it in a few months, so I'll do it soon eventually.
Just watch.
(Actually, I've already tried it a few times, and I rarely reuse existing code. It will be a completely rewritten codebase)
The text was updated successfully, but these errors were encountered:
TL; DR: I will build a new esbuild-powered build tool, called "espub"
Brief history of nanobundle
nanobundle, as the name suggests, is a bundler. It aimed to provide effortless library building by adding some tweaks to esbuild's bundle mode. It's just like what microbundle does based on Rollup, that first inspired.
In v1, I focused on leveraging the full power of conditional exports in Node.js. And since TypeScript didn't support multiple entries at the time, this was a reasonable compromise. As a result, it was sufficient to support “small libraries” use cases and is compatible with the TypeScript ecosystem without noise.
Current status of nanobundle
I still use nanobundle actively in my daily work.
But at the same time, I see numerous cases where nanobundle is not a good fit because it is essentially a "bundler".
The bundler, by definition, removes the module semantics from the output after it has been performed. So I can't build things that depend on module semantics (I can approach it "cleverly", but it's overly complex or unpredictable)
While I was recognizing its limitations, I stopped exploring further features. And waiting for the ecosystem to move.
Time passed and things changed.
TypeScript projects can now adapt Node.js's conditional exports with the new
moduleResolution
modeNode16
,NodeNext
andBundler
Import attributes spec is standardized, and esbuild has added support recently. So users can specify more options at the module level. no need to customize loaders within the config.
XState v5 is released. It supports a better concurrency model than before with first-class actor support.
So what's the plan?
I still have trouble finding build tools that work for me in many situations.
Type checking is performed independently. tsc/babel is too slow to transpile. Most tools still don't handle conditional exports correctly. And more importantly, I moved most of my projects to ESM-first. I don't want to "bundle" my lib codes anymore.
It seems like there is still a chance to build a perfect esbuild wrapper. So I will do that.
It will be rebranded under the name "espub" because it is no longer a "bundle"-first tool. It will still be able to bundle stuff, maybe I can keep the "nanobundle" as its alias.
ETA?
I'm definitely exploring in this Dec, but I can't promise anything.
I'm personally having productivity issues, and I also have other projects I'm involved with. Maybe you can make it faster than me.
I've actually seen a few close ones like tshy, pkgroll and bunchee. Unfortunately, none of them isn't for me. I don't expect someone to build it in a few months, so I'll do it soon eventually.
Just watch.
(Actually, I've already tried it a few times, and I rarely reuse existing code. It will be a completely rewritten codebase)
The text was updated successfully, but these errors were encountered: