@ms-cloudpack/bundler

This library provides an abstraction on bundling a package, assuming that the package is conformant.

Rather than directly depending on Webpack, rollup, or esbuild with large amounts of custom configuration, having an abstraction around bundling provides constraints around having common inputs/outputs.

This enforces the code follow consistent constraints, while also ensuring the output can be consumed in the browser or in node depending on supported environments.

Abstraction also allows us to use the right tool for the job. The right tool depends on priorities and capabilities. For dev builds we want the fastest tool, while for production we want optimal output. For library mode builds on commonjs only packages, esbuild doesn't emit named exports while rollup does. Maybe later esbuild will address that issue, so we can adjust the regulation logic accordingly.

Usage

async function bundlePackage(options)

import { bundlePackage } from '@ms-cloudpack/bundler';

async function start() {
  const result = await bundlePackage({
    packagePath: process.cwd(),
    outputPath: path.join(process.cwd(), 'dist'),
    outputType: 'library',
  });

  console.log(result);
}

start();

bundlePackage options

| Name | Type | Description | | ----------- | ------------------------------ | ------------------------------------------------------------ | | packagePath | string | Path to the package root where package.json lives. | | force | boolean | Bypasses the cache to create bundles. | | hashFrom | "package-version" | "git" | Determines how the cache key is computed for bundle results. | | output | "library" | "app" |

Return object

| Name | Type | Description | | --------- | ---- | ----------- | | stats | | outputMap |

Details

The Cloudpack bundler abstraction is simple and constrained on purpose:

1. Consume a standard package (app or library) with a minimum set of requirements.
2. Emits standard ESM bundle.
3. Leverages package.json and convention as much as possible:

This library has only 2 output modes:

• library mode - produces a bundle of source which externalizes dependencies and is consumable by the target (browser or node) which can resolve the dependencies through an import maps in the browser or through module resolution in node. The source is unminified.
• production mode - produces a bundle of source which includes dependencies and is also similarly consumed.

Package requirements

Discovering entry points

Entry points are discovered by analyzing the package.json. This ensures only explicit entries are bundled.

ESM output

Considerations

Leverage existing task runners

Under the hood, if we want to separate the process into multiple steps, we may consider using task helpers like just-scripts or heft to execute things in the right order. This might help

Splitting the "bundle" abstraction into pre/bundle/post steps