Use Vite (again)

[mrm007]

This PR reintroduces Vite for bundling/packaging modules (crackle package) e.g. for precompiled Braid.

The major changes are

• replaced our custom Rollup config in bundle.ts with Vite
• introduced a Rollup plugin to resolve paths to CJS modules (used in ESM mode)
• ESM bundles now use .mjs extension

This PR was tested in:
✅ Braid site with Crackle snapshot
✅ braid-site fixture with Braid snapshot
✅ Gotham candidate site with Crackle and Braid snapshots

Replaced Rollup with Vite

This one was pretty straightforward, as the hard work was already done by @mattcompiles and @benjervis before upgrading to Vite 3 (library mode was broken in Vite 3 so we had to go to Rollup). As of version 3.1.3, lib mode works again.

With the release of 3.2.0-beta.0, the fix for the SSR build issue is in so the legacy behaviour is no longer needed.

Added a Rollup plugin to resolve paths in ES Modules

The Rollup plugin combines the functionality of rollup-plugin-node-externals with the build.ssr fix. Why is this needed? Two reasons:

1. In ESM mode import specifiers are a bit more restrictive than in CJS mode:

   Bare specifiers like 'some-package' or 'some-package/shuffle'. They can refer to the main entry point of a package by the package name, or a specific feature module within a package prefixed by the package name as per the examples respectively. Including the file extension is only necessary for packages without an "exports" field.

2. Vite prefers ESM so if it finds an ESM version of a package/import it will load it unmodified. The SSR build (i.e. crackle build) will fail if an import specifier refers to a file (import mapValues from 'lodash/mapValues') or a directory (import parse from 'autosuggest-highlight/parse).

So the Rollup plugin wraps rollup-plugin-node-externals and

1. lets rollup-plugin-node-externals decide if an import is "external"
2. if the import is external
3. and it's a subpath import (e.g. lodash/mapValues or @scope/something/other)
4. and the module's package.json doesn't have an "exports" key
5. and we're building for ESM
6. then we patch the import id to a file using the same logic as the Vite build.ssr fix

This fix also removes the need to have a hardcoded list of exceptions for crackle start (related to this Vite issue).

ESM bundles now use .mjs extension

Practically, there are two ways Node will treat a file as an ES Module:

• it use an .mjs extension
• it use a .js extension with type: "module" in the nearest parent package.json

The implication (?) is that a file with a .cjs extension is always treated as a CommonJS module and a file with an .mjs extension is always treated as an ES Module. So, if we save create bundles with .mjs and .cjs extensions we can publish packages that work in both environments 🎉.

[changeset-bot]

🦋 Changeset detected

Latest commit: 79b70ea

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@crackle/core	Minor
@crackle/cli	Patch
@crackle-fixtures/braid-site	Patch
@crackle-fixtures/single-entry-library	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[benjervis]

Nice, good to get back to a single bundler 🎉

[benjervis]

Given that we own externals now, could the pre just be rolled into the plugin, rather than having to spread here?

[benjervis]

Once you start adding in asyncs, I find this inline key function definition style really unclear that it's part of an object. Could we go with buildStart: async(options) => {, etc?

[mrm007]

I agree, however changing the meaning of this breaks the plugin so we can't use an arrow function. This

buildStart: async function (options) {}

gets ESLint-fixed to

async buildStart(options) {}

[benjervis]

I think the dep on mlly has been deleted in the package.json?

[mrm007]

It's still there, just synced it to Vite's version so the diff is a bit more noisy.