chore: Migrate build tool

[mttrbrts]

Migrate from webpack to rollup for bundling. Rollup is more appropriate for a library such as this, whereas webpack is better suited to web apps. This also aligns this repo with @accordproject/web-compoennts

Changes

1. The browser bundle has moved from umd/concerto.js to dist/concerto.min.js.
2. Tuning .npmignore.

[jeromesimeon]

Migrate from webpack to rollup for bundling. Rollup is more appropriate for a library such as this, whereas webpack is better suited to web apps. This also aligns this repo with @accordproject/web-compoennts

Changes

1. The browser bundle has moved from umd/concerto.js to dist/concerto.min.js.
2. Tuning .npmignore.

This looks nice, but also slightly disconcerting. A bit curious about:

1. tradeoffs between webpack and rollup: why is rollup better for this kind of library? also based on the description, shouldn't web-components use webpack?
2. why do we care about bundling at all. Could we just remove it completely? wouldn't web components end up bundling concerto anyway?
3. why now? what problem are we trying to solve?

[mttrbrts]

1. tradeoffs between webpack and rollup: why is rollup better for this kind of library? also based on the description, shouldn't web-components use webpack?

There are lots of comparisons out there, e.g. https://betterprogramming.pub/the-battle-of-bundlers-6333a4e3eda9

web-components is a library for building web apps, but is not a web app itself.

2. why do we care at all, wouldn't web components end up bundling concerto anyway?

By bundling and performing optimisations such as tree-shaking and minimisation, all dependencies of concerto benefit from reduced package sizes. Optimising here also gives us greater control than relying than on upstream dependants. Our npmjs listing today, says that our package size is >1MB which is misleading at best (the compressed version of the UMD bundle is ~80kB), and suggests many other poor things at worst. As the root package in the AP stack, I wanted to start my investigations here because it will give us the biggest ROI.

3. why now? what problem are we trying to solve?

I originally attempted to solve a different problem, then rolled-back and this PR is what remained.

Currently, in the npm package that is published by this repo, we include two things that are redundant:

1. The source files in the lib/ folder
2. A UMD bundle of the source files in the umd/ folder.
   You can run npm pack @accordproject/[email protected] to view the contents of the published package, or just npm pack to build the package .tgz locally.

UMD is compatible with Node JS and browsers, but other formats are preferable (ESM for Node, and IIFE for browsers). However, after investigation, I wasn't confident that I had a solution that solved this problem and retained CommonJS for developing / testing locally. I might pick this up again, but I need to move onto other things now.

I was also hoping that a switch to Rollup would give us an improvement in the size of the UMD bundle; it didn't, it's broadly the same.

Another conclusion was that to really benefit from a performance optimisation, changing the bundle format (UMD vs IIFE vs CommonJS vs ESM) makes margin impact because of the dominance of the parser which is more than 90% of the total package size. This is further motivation for #55 (comment)

[jeromesimeon]

1. tradeoffs between webpack and rollup: why is rollup better for this kind of library? also based on the description, shouldn't web-components use webpack?

There are lots of comparisons out there, e.g. https://betterprogramming.pub/the-battle-of-bundlers-6333a4e3eda9

Another benefit of WebAssembly was staring us in the face all along.

web-components is a library for building web apps, but is not a web app itself.

gotcha.

1. why do we care at all, wouldn't web components end up bundling concerto anyway?

By bundling and performing optimisations such as tree-shaking and minimisation, all dependencies of concerto benefit from reduced package sizes. Optimising here also gives us greater control than relying than on upstream dependants. Our npmjs listing today, says that our package size is >1MB which is misleading at best (the compressed version of the UMD bundle is ~80kB), and suggests many other poor things at worst. As the root package in the AP stack, I wanted to start my investigations here because it will give us the biggest ROI.

Understood, but clearly this looks like an investigation and if we like it, it feels like we are signing up for applying this to the rest of the AP stack (or feels like we should which is a pretty significant effort).

1. why now? what problem are we trying to solve?

I originally attempted to solve a different problem, then rolled-back and this PR is what remained.

Currently, in the npm package that is published by this repo, we include two things that are redundant:

1. The source files in the lib/ folder
2. A UMD bundle of the source files in the umd/ folder.
   You can run npm pack @accordproject/[email protected] to view the contents of the published package, or just npm pack to build the package .tgz locally.

UMD is compatible with Node JS and browsers, but other formats are preferable (ESM for Node, and IIFE for browsers). However, after investigation, I wasn't confident that I had a solution that solved this problem and retained CommonJS for developing / testing locally. I might pick this up again, but I need to move onto other things now.

I was also hoping that a switch to Rollup would give us an improvement in the size of the UMD bundle; it didn't, it's broadly the same.

Another conclusion was that to really benefit from a performance optimisation, changing the bundle format (UMD vs IIFE vs CommonJS vs ESM) makes margin impact because of the dominance of the parser which is more than 90% of the total package size. This is further motivation for #55 (comment)

Looks nice all around though, I'll approve and let's see how it goes.

[jeromesimeon]

Looks nice as a migration away from webpack.