rolling up the code

Recently I came across the typescript-library-starter repository on Github as well as a few other feeds I read. Around the same time I was part of a discussion in one of the projects regarding the ability to make it easier for external organizations to integrate with our system. Cutting a very long story short, we more or less decided for a proof of concept of how to create a “modern” widget.

Now, don’t get me wrong, the days of Java Applets, Flashplayers are somewhat over, but the idea of standardising a small library for external use is tempting. These days we (in this particular project) know very little in regards to how our users systems work (municipalities, large older companies).

---

Putting one and one together, and the idea of investigating this proof of concept, more or less equates (in my mind) to testing out the typescript-library-starter.

This starter comes with a preset of powerful tools (like most boilerplates), often well-known across the web development community, but what stood out most wasn’t the typescript, the prettier or the numerous npm hooks available.

Two months ago, as of writing, a large pull-request showed up in the react github repository which more or less switched out Facebook’s current build process with one of the new kids in town, rollup. This definitely resonated through the communities, sparking the good old black and white discussions of: is x better than y.

I won’t repeat the why or the how, because the rollup docs does a much better job. But I found the experience of no longer detailing a rather long webpack configs, but instead defining a very clear and small top-down priority of processes (much more reminiscent of Gulp in comparison) rather pleasant.

Admittedly, at the end of the proof of concept, my rollup.config.js looks much more like the webpack-config files that many of us are used to. It grew as I added preact, buble, progress-bars, filesize-tables, livereload and much more. Add development checks, static file paths and I feel right at home again.

---

“Is it better?” - you ask.
Objectively better in all possible ways? No!

For this particular use case? Probably!
I can definitely see the good parts when it comes to writing library specific code, because it becomes apparent already at the start regarding the options you have in terms of the output of your code. UMD, AMD, ES6 or just CommonJS modules. Or why not simply output them all?

I don’t see much reason to discard x for y, because they are very similar in concept. If you feel you have come to terms with one of the two mentioned, the other shouldn’t feel much different.

If I have any verdict, it would be the following: TypeScript and rollup makes for a good combination when authoring a library and I’m grateful for the author of typescript-library-starter for introducing me to both.

I’m still saving another post for my opinions regarding TypeScript because I haven’t spent enough time with it.