Xstate: Upgrade to Webpack v4

[davidkpiano]

This issue is to track upgrading xstate to Webpack v4, especially for making the package tree-shakeable, which it should already be capable of doing, since all files are side-effect-free.

We will also want to set up a single configuration file so that we output four separate files:

• xstate.js (the core xstate Machine creator)
• xstate.utils.js (graph and testing utilities)
• xstate.patterns.js (helpful state machine patterns, such as toggles, sequences, promises, etc.)
• xstate.interpreter.js (the default xstate interpreter, with inspiration from @avaragado's xstateful)

[Andarist]

I'm up for the task - but I'm not sure what we want to achieve here, so I'd like to establish it first.

In general when consuming this package bundlers reach out for files generated by TS - the ones specified in main & module entries of the package.json.

webpack is used here merely to create UMD filed & they are most commonly non-treeshakeable & also their usage is rather niche. Also - you could (I could help with that) switch to rollup for generating them as in general it does a better job when it comes to bundling libraries.

What could be done is to annotate all top-level calls with #__PURE__ comments to let UglifyJS eliminate them as dead code (if their results stay unused ofc). This can be automated.

[davidkpiano]

I would be open to using Rollup 👍

[Andarist]

I'm still unsure about the goals though, should I just rollup 4 separate (self-contained) UMD bundles? Or should I flat bundle the library into 4 files but with shared (common) parts?

[Andarist]

friendly 🏓

[davidkpiano]

@Andarist Sorry for the late reply!

Or should I flat bundle the library into 4 files but with shared (common) parts?

^ This - the main xstate.js bundled file should be self-contained, though. The others can depend on it.

[davidkpiano]

Closing this - using Rollup instead.