Replace Parcel with Rollup for manifest builder

[pittst3r]

Motivation

I was initially attempting to upgrade to parcel@2 because:

• Typechecking
• Parcel errors if your app has parcel@2 installed while Bigtest is using parcel@1

After struggling with this I noticed:

• We are having to do gymnastics in order to run Parcel (v1 and v2) in a safe way; specifically we are needing to run it in its own process so we can kill the whole group as it creates a bunch of child processes that don't shut down on their own
• Neither the parcel@1 nor parcel@2 JS API are nice to use
• We don't need the Parcel server feature, just a watched build

Approach

Rollup is a better fit for the problems at hand:

• Has a first-class JS API
• Does not require its own sandboxed process group

This PR switches to using Rollup for bundling the manifest.

To-do

Typechecking and linting of test code is still a problem. I was unable to get @rollup/plugin-typescript to behave well, so I fell back to using Babel to compile TypeScript, which does not do any typechecking. I think it may make sense to typecheck and lint as a separate step anyway if a tsconfig.json or .eslintrc.json are found.

[changeset-bot]

🦋 Changeset is good to go

Latest commit: a3d2bac

We got this.

This PR includes changesets to release 3 packages

Name	Type
@bigtest/bundler	Minor
@bigtest/server	Minor
@bigtest/cli	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

[github-actions]

The preview packages of this pull request have been published.
Click on the following packages for instructions on how to install them:

@bigtest/atom

---

Install using the following command:

$ npm install @bigtest/atom@rollup

Or update your package.json file:

{
  "@bigtest/atom": "rollup"
}

---

@bigtest/bundler

---

Install using the following command:

$ npm install @bigtest/bundler@rollup

Or update your package.json file:

{
  "@bigtest/bundler": "rollup"
}

---

@bigtest/effection

---

Install using the following command:

$ npm install @bigtest/effection@rollup

Or update your package.json file:

{
  "@bigtest/effection": "rollup"
}

---

@bigtest/globals

---

Install using the following command:

$ npm install @bigtest/globals@rollup

Or update your package.json file:

{
  "@bigtest/globals": "rollup"
}

---

@bigtest/interactor

---

Install using the following command:

$ npm install @bigtest/interactor@rollup

Or update your package.json file:

{
  "@bigtest/interactor": "rollup"
}

---

@bigtest/server

---

Install using the following command:

$ npm install @bigtest/server@rollup

Or update your package.json file:

{
  "@bigtest/server": "rollup"
}

---

Generated by 🚫 dangerJS against a3d2bac

[jnicklas]

@pittst3r 🥳 🎈

[cowboyd]

This ought to simplify things considerably, way to turn a chore into an architectural upgrade!

[cowboyd]

This is an interesting case of whether to use subscribe vs Subscribable.from. The first subtle difference is that the first maps an actual live subscription, whereas the latter maps an operation that produces a subscription.

From a runtime perspective, subscribe() produces a single subscription (tantamount to a single event listener) shared by both waitForSuccessfulBuild and createManifestBuilder vs two subscriptions, one at each site of iteration you would get from Subscribable.from. From a code perspective, subscribe() requires an extra yield statement and type annotation.

Otherwise, they're identical. I'm not sure I understand the tradeoffs fully, but wanted to at least highlight the differences for this use-case so that we can collect more datapoints. /cc @jnicklas

[pittst3r]

One (fixable) problem with using Subscribable.from() is the Chain interface is not public, making type annotations with it impossible. This is not a great reason, but it was my deciding factor in this case. I do feel that subscribe() may be a better fit though as we would otherwise be recursively creating new subscriptions in waitForSuccessfulBuild() if I understand correctly.

As an aside, the overlap between Subscribable and Chain and ChainableSubscription is confusing to me. Not sure if there's room to make the differences more clear and understandable or otherwise consolidate into fewer interfaces.

[jnicklas]

I initially wanted to remove Subscribable entirely, but we left it in there, because we didn't know which type of chaining would turn out to be more useful, so we decided on keeping both. That being said, we could certainly improve on the naming of things to make it easier to understand.

[cowboyd]

@pittst3r seems like the right choice for a recursive method, although this is a very subtle distinction to ask users to

I wonder if we can make some shared interface that has all the chaining, and then have the low-level thing that just has next() on it a SubscriptionIterator. We might be able to use that chaining interface regardless of whether we're chaining the subscription or the operation.