Consider ditching Webpack

[drzax]

Webpack has been good to us, but there are now new, possibly better options that might open up new possibilities for what we can do with aunty.

This is a ticket to discuss the pros and cons of sticking with Webpack and what it would take to make a switch. What, if anything, is tying us to Webpack right now?

aunty's current utility is three things:

• project bootstrap
• dev server and final builds
• ftp for versioning and deploy

This ticket relates to the second item on that list — dev server and builds. But if we have a build capability for packages, we may also want to consider what else might be useful around publishing (e.g. we've used np in the past for better publishing to NPM).

One thing a change might facilitate is adding the ability to build libraries for distribution via NPM or for use as dynamic imports. An example in this space is tsup which is a build tool for packages that essentially wraps esbuild and typescript.

There are ABC News libraries already using it (and an example using esbuild directly) however it's not suited to aunty's main job and is opinionated in ways that don't suit our requirements.

Another option worth considering is vite which is a Webpack replacement which is a wrapper around Rollup which is more capable at building projects for packaging and distribution.

[phocks]

Good idea. I'd ideally like the option either make a Webpack project or Rollup/Vite/Snowpack etc, but then we'd have to support every build tool we add.

I'll throw SWC into the mix too. Rust build JS project bundler that is used by Vercel. Heaps fast. https://swc.rs/

[drzax]

@phocks What's the use case for continuing to support webpack as an option rather than just switching?

[drzax]

I've started work on making aunty serve use Vite instead of Webpack. I'm going to use this comment to document some of the issues encountered.

• Vite should fit relatively neatly into the way aunty's config generation already works.
• Unlike Webpack, Vite considers the .html file(s) to be the main entry point and treats them quite differently. To get around this we could possibly force vite to do things it doesn't want to do with custom middleware or we could re-arrange the default project structure a bit. I prefer the second option, but it would be a fairly significant breaking change.

[colingourlay]

Break all the things! This is such a worthwhile shake-up, especially if it means we can bring in libraries-as-first-class at the same time

[phocks]

@phocks What's the use case for continuing to support webpack as an option rather than just switching?

Somehow totally missed this reply. But yeah now I reckon it would be cool to just switch to Vite. Although doesn't Vite just use Rollup under the hood, which from my experience is maybe better suited to npm package creation while Vite is more suited to web app creation with a .html entrypoint?? Not sure. If you can get Vite building reusable packages then awesome.

[drzax]

If you can get Vite building reusable packages then awesome.

You might be right, but it definitely considers itself useful for packaging libraries: https://vitejs.dev/guide/build.html#library-mode

[phocks]

Oh nice. I hadn't seen this feature. Excellent! OK let's go for it!

[drzax]

We've decided to go ahead with this change. Closing this ticket now. General discussion can continue in #173. New issues should be opened for discussion on specific issues.