Convert to full ESM & bundle dependencies

philcockfield / file-system-cache

A super-fast, promise based cache that reads and writes to the file-system.

MIT License

51 stars 14 forks source link

Convert to full ESM & bundle dependencies #47

Closed ndelangen closed 2 months ago

ndelangen commented 4 months ago

I'm using the amazing TSup to create the lib folder instead of tsc
The lib actually contains ESM rather than CJS (tsconfig.json was setup to output CJS and tsc respects that setting.
TSup is able to bundle dependencies for both the lib/index.js as well as lib/index.d.ts, so I set it to bundle in everything. This makes the package dependency-less (total lib size is 91.34 kb).
Upgraded all dependencies
Switch to using the ESM version of fs-extra.
Added a format command (prettier config was already present, but couldn't be used)

ndelangen commented 4 months ago

FYI we're using this package in Storybook.

When we're compiling our package, we get these warnings:

"default" is not exported by "../node_modules/file-system-cache/node_modules/@types/fs-extra/index.d.ts", imported by "../node_modules/file-system-cache/lib/common/libs.d.ts".
"default" is not exported by "../node_modules/@types/ramda/index.d.ts", imported by "../node_modules/file-system-cache/lib/common/libs.d.ts".

This prompted me to have a look inside, and attempt to do some upgrades/improvements.

Looking forward to your feedback @philcockfield

philcockfield commented 2 months ago

Thanks for the refactoring into tsup - if you're using that on Storybook, then merged into this module it is sir. Appreciate your effort @ndelangen

philcockfield commented 1 month ago

Hey @ndelangen, out of interest, I'm assuming you've pushed Storybook to be full ESM, with no CJS legacy support?

I am a supporter of this, which is why I merged your PR...we need to get to ESM broadly as a community and get away from legacy that is just pure heat loss.

That being said, a number of folks are having the inevitable issue of being punched in the face by the CJS/ESM dichotomy.

Have you guys just taken a strong "NO CJS" support with Storybook, and are just wearing the push back - or are you doing a dance with dual-output bundling?

ndelangen commented 1 month ago

@philcockfield thanks for the interest, I'm happy to answer.

We're in the process of going full ESM. We've taken many steps towards this goal already, but have not yet made the full plunge just yet.

Our packages compile using TSup to both ESM and CJS, as well as generate a type definition bundle.
We have type=module on some packages, but not many
We use export maps in our package.json to ensure modern tools can pick the file formats that suits them/is appropriate for the way our packages are consumed.
We've reduced the number of packages is comprised of and removed complexity in our package structure/architecture.
We've upgraded/switched many dependencies to ESM.
We prebundle many of our dependencies, so them being ESM or CJS doesn't matter a lot, and even when some ESM<>CJS funny stuff goes on, we can make it work that way.

We plan on making a jump to be ESM only or at least "ESM first" by Storybook 9.0, which is scheduled for release in January 2025.

It's a massive shift, and possibly going to be a bumpy upgrade for some users, if they use storybook in unexpected/unknown ways. But it is a change that's really needed for the ecosystem to progress, but that's just my humble opinion.