Worklet support

[ProLoser]

↪️ Pull Request

Support for worklets.

💻 Examples

import url from 'worklet:./my-worklet.js'

🚨 Test instructions

✔️ PR Todo

• Added/updated unit tests for this change
• Filled out test instructions (In case there aren't any unit tests)
• Included links to related issues/PRs

[height]

Link Height tasks by mentioning a task ID in the pull request title or description, commit messages, or comments.

💡Tip: You can also use "Close T-X" to automatically close a task when the pull request is merged.

[devongovett]

Can you give us some context about why this plugin is necessary?

[ProLoser]

@mischnic perhaps you could speak to this?

[ProLoser]

I'm not really sure how this.#value.symbols is used, the worklet or worker will likely not be able to share dependencies with the main javascript thread (for now) so I'm curious if this is an attempt to prevent the asset from having additional globals or other dependencies incorrectly bundled into the asset during packaging?

[mischnic]

This is purely to workaround the foo.js does not export 'default' error when doing import x from "worker:./foo.js", has nothing to do with shared bundles.

An alternative is special-casing asset.isIsolated in the symbol propagation logic itself.

[ProLoser]

I wouldn't need this branch merged if I knew how to run parcel commands without having it mess with the dependencies, is there a flag for that?

[mischnic]

1. (Turn your project into a monorepo)
2. Add the newly added transformers to your project as packages
3. Add them to the parcelrc

[ProLoser]

1. Already a monorepo
2. I copied transformers/clear, transformers/worker, transformers/worklet
3. Add them to the .parcelrc

Cleared node modules and reinstalled, I'm getting lots of packaging headaches. I've also tried making the parcel repo a submodule (on the worker-url branch) and adding "parcel/packages/*/*" to my package.json#workspaces[] but it's nothing but dependency headaches and version mismatches.

[mischnic]

I haven't had any problems so far with adding a Parcel plugin to a monorepo, for example here: https://github.com/mischnic/parcel-resolver-root. example would be your project

[ProLoser]

Okay I got it working and it was really easy in the end:

cd myProject; git submodule add -b worker-url https://github.com/parcel-bundler/parcel.git parcel

and then I updated my monorepo config:

// myProject/package.json
{
	"workspaces": [
		  "packages/*", // mine
		  "parcel/packages/*/*" // yours
	],
	"dependencies": {
		"parcel": "2.0.0-beta.1"
	}
}

The problem I had was I was previously using nightly releases, but the packages from worker-url are set to 2.0.0-beta.1 and I really don't want to keep manually updating those with every nightly.

So instead, I decided it's easier to treat the entire parcel dependency tree as a submodule that I can checkout whatever version I want. To get the dependency to work correctly, I had to ensure that my root package.json was pointing to the same version as the one specified in the submodule, or else the submodule would not be considered a recent enough release to satisfy the dependency (even though the source code itself IS in fact newer).

I would recommend these instructions for simplicity and minimal dependency headache in the future ^

[ProLoser]

I should mention that the way you guys are setting up your dependencies on @babel/core is causing multiple copies of babel to be resolved in different packages.

I would recommend peaking at your yarn.lock and running yarn why @babel/core to see how many versions are being resolved. I'm seeing @babel/core@7.12.9, @babel/core@7.12.16 and @babel/core@7.12.17. Although deleting my yarn.lock and reinstalling deduplicated them, but either way I was concerned this may cause 2 separate javascript memory runtimes in parcel, or you know like loading the same file in 2 locations.

[ProLoser]

I'm still seeing this when I do a build instead of serve

[ProLoser]

I've seen this typically when running built files. The build succeeds but running the code does not. Serving the files succeeds and running succeeds.

[mischnic]

Sounds like #5816

[ProLoser]

Yup that looks like what I'm experiencing and it looks like it was fixed after this branch was created

[ProLoser]

I rebased this branch on top of the latest v2 locally and tried building again but it's still showing up for me :/ any tips what I should be looking at?