The Interledger Community 🌱

Jesse von Doom
Jesse von Doom

Posted on

Bundling a front-end library?

#question #infrastructure #webpack #rollup

Hey there — wondering if anyone here has experience with tools like webpack and rollup.js when it comes to bundling a front-end library? (As opposed to an app for deploy.)

We've been evaluating rollup and webpack, with pros and cons to each. Like any library we've got a few dozen "oh yeah but..." requirements. Code could use a refactor. All that. This is going to get more important in the next few months, but isn't a top priority right now.

I'm not looking for an answer to a specific issue, but hoping to see examples of how other front-end libraries are broken up for easier community development and packaged up for release. I've found a few, but would love any thoughts?

Top comments (6)

Collapse
 
yawnxyz profile image
Jan Zheng •

This is all new to me, but I've been trying to follow Svelte / SvelteKit's progress and their process of moving to Vite. Another interesting player in the space. They had a few good writeups and presentations on why they moved to Vite from Snowpack

Collapse
 
jessevondoom profile image
Jesse von Doom •

We've just started embracing Vite more and work and wow I wish I'd found it sooner. Really, really impressive using it! Hadn't even thought about this use case in a minute and yeah I think you're on to sometihng.

Collapse
 
radhyr profile image
Radhy • • Edited

Same here, been following SvelteKit and Vite progress for a while. Previously I've been following Snowpack solely because SvelteKit, and now that SvelteKit has migrated to Vite, I'm starting in getting touch with Vite. Tried to migrate my Sapper + Webpack project (which is currently being proposed to GftW!) to a whole new SvelteKit + Vite setup because my laptop is at its limit opening VS Code + Nodejs webpack dev server + MS Edge at the same time, but met with circular dependency issue that prevents me from doing so.

At the moment my solution to my problem is basically ditch Windows 10 for a lighter Ubuntu. But still, can't wait the day to wholly work on all my projects on SvelteKit and Vite!

Collapse
 
radhyr profile image
Radhy •

I have miniscule experience of bundling frontend library but I got started by copy paste'd a whole repo from library idb-keyval (rollup) since I want a ready-to-be-used typescript frontend package template. I did this to mostly figure out the "basic" structure of popular library that is heavily used in real world.

Don't know if this gonna add to something, but as my fine grain of salt opinion, here what the most notable lessons I learned by doing that:

  1. The very first mistake that I made is that I assume bundler controls the package entry, but it is done in package.json -> main (that should be pointing out to main output file). It kinda obvious but looking back it is easy to miss for someone who mostly made apps with bundler and only have to worry about npm run in package json.
  2. Providing TS types is kinda important with people migrating to TypeScript nowadays. I don't want to be that one library author who gives devs headache to declare types any for my library because lack of type support (though I'm still suck in static typing and writing TS documentation).
  3. Personally, I found rollup to be better and simpler for authoring frontend library since most of the time a frontend package wouldn't need webpack's elaborate build pipeline.

A frontend library for my taste would be:

  1. Have typescript + babel + jest ready with babel plugins optional chaining and nullish coalescing operator added in.
  2. One .ts file as bundler entry that only contains TS export, eg export { myFunc } from "./other-script.ts";. Keeping the entry .ts file clean with export only makes it easier to see which functions are being exposed when being imported in apps, with benefits of easier refactor IMO.
  3. Publish with to npm with tools like np. Till this day, I haven't learned how to make github release manually since np did it all for me.
Collapse
 
jessevondoom profile image
Jesse von Doom •

Thanks for all this, and sorry I didn't see it sooner. Yeah I think rollup of ESM module code for the front-end will ultimately be the way I go here. Not even doing typescript — all vanilla JS but breaking up a 1500 line monolith seems like it'll make everything so much easier to work with, especially as an open source project.

And yeah good call looking at an existing project. Made some progress on the research front but hands-on learning for this one seems a lot easier/faster.

Collapse
 
radhyr profile image
Radhy •

So I have following on Snowpack recently, though still not dipping my toes on it. In recent major update they have their own bundler now. I still haven't figured out whether it is good enough for a frontend library project, but I think it's a good project to keep a tab on.