Parcel: [RFC] Run Parcel in the browser 💥

Created on 26 Apr 2018 · 14Comments · Source: parcel-bundler/parcel

I chatted with @CompuIves (author of Code Sandbox) at React Amsterdam about potentially running Parcel fully inside the browser. They do this in Code Sandbox using their own bundler currently, but it would be cool if we could enable them to use more pieces of Parcel.

In addition, it would be super cool to have an online demo showing how Parcel works, similar to the one Rollup has. Maybe we could even just use Code Sandbox for that. 😜

There are a few things that we currently depend on Node for that won't work in the browser.

Workers - We could use web workers in the browser instead of processes. With the new worker farm implementation that just landed this should be easier.
Filesystem - We could abstract the filesystem so there could be a node implementation, and a virtual filesystem implementation for the browser.
Server/HMR - can't run an HTTP server in the browser, but maybe we could abstract this too so you could plug in a different HMR implementation via events or something.
Cache - use an in memory cache instead of a filesystem? Maybe something like indexeddb if we wanted to persist?
Native modules - there are some like the SASS compiler that won't work, but could probably be compiled to webassembly.

These should all be solvable if we make Parcel sufficiently pluggable so that these pieces could be replaced with alternative implementations, even if they aren't all provided by Parcel itself. For example, there might be many implementations of a filesystem, not just a single browser one that we provide. We'd want to allow e.g. Code Sandbox to implement their own and plug it into Parcel easily.

This is kind of a meta issue to discuss the above items. We can break out into separate issues to discuss each one as we get closer to implementation. For now, let me know your thoughts!

RFC ✨ Parcel 2

Source

devongovett

❤19 🎉12 👍6 🚀3

Most helpful comment

I've taken a go at this (the Rollup-inspired REPL, not a Codesandbox-like IDE; though there is a preview iframe) by make Parcel self-hosting, if someone wants to try it

https://parcel-repl.now.sh/
code in the repl branch
some details on the process

Actual code changes to Parcel were pretty minimal, so I hope this will be comparatively easy to port to Parcel 2.

mischnic on 1 May 2019

👍17

All 14 comments

This sounds great, I'd love to help wherever I can!

I agree with the given points. The solution to some native modules would be to create browser specific transpilers (eg. Sass.js instead of node-sass), that wouldn't be too hard to implement I reckon.

I'm looking forward to more discussion on this, I'd really love to have Parcel working inside CodeSandbox 😄

CompuIves on 26 Apr 2018

Awesome idea!

Filesystem : Ping @DeMoorJasper. We've discussed a bit about implementing a virtual fs in Parcel, perhaps this may help in this issue? IIRC CodeSandbox already has its vfs.
Server/HMR - As we only serve static files we could totally polyfill this only using Object URLs (URL.createObjectURL) and use a internal messaging system instead of WebSockets.

A concrete index.html example :

<!DOCTYPE html>
<html>
  <head>
    <title>Code Sandbox + Parcel</title>
    <link
      rel="stylesheet"
      href="blob:https://github.com/9defa61c-87c6-49b4-a3a8-2d9616941f33"
    />
  </head>
  <body>
    <script
      src="blob:https://github.com/8defa61c-87c6-49b4-a3a8-2d9616941f33"
    ></script>
  </body>
</html>

fathyb on 26 Apr 2018

Awesome!

FS: Virtual fs would definitely be a nice feature, it would help in some issues that are quite complex to solve right now and might improve performance.
HMR: Abstracting HMR to a simple event listener would probably make browser implementation insanely simple.
Workers: We could throw the workerfarm into a seperate package and document the api properly, so it could be easily changed to webworkers for browser usage. I've been experimenting with the workerfarm and running it inside the browser and the browser workers wouldn't be as complex as the workerfarm we have so it'd be a rather big change. Seperate swappable packages would solve this. Also #1235 would add ability for plugins to utilise the workerfarm in a very abstracted way, so the plugin dev will not have to worry about anything worker related while still having the performance improvement if they need it.

DeMoorJasper on 26 Apr 2018

👍2

Let me know if there's progress here, I'd love to be involved 😄

CompuIves on 14 Jun 2018

🚀1 👍1

I've taken a go at this (the Rollup-inspired REPL, not a Codesandbox-like IDE; though there is a preview iframe) by make Parcel self-hosting, if someone wants to try it

https://parcel-repl.now.sh/
code in the repl branch
some details on the process

Actual code changes to Parcel were pretty minimal, so I hope this will be comparatively easy to port to Parcel 2.

mischnic on 1 May 2019

👍17

Hi, I've been down a few rabbit holes trying to replicate similar functionality. Just stumbled on this thread and I'm wondering how far off these features are?

Are there any work arounds that I could use in the meantime? My app is very much in an alpha stage so keen to test things out early!?

Please give extra info if possible. I've not used Parcel before, and find the bundler world a bit 🤯

Thanks in advance and great work so far!

danvoyce on 1 May 2020

Same here. We're creating a web-based IDE and need a bundler that can work with a virtual file system. I'm keen to learn whether this will be possible with Parcel any time soon.

DanielSWolf on 6 Jul 2020

Technically, Parcel 2 can already run in the browser.

A REPL (similar to the Rollup one): https://parcel2-repl.now.sh
Code for that: https://github.com/parcel-bundler/parcel/tree/repl-v2/packages/dev/repl
(That build/branch is slightly outdated compared to the "normal" Parcel)

Current bugs of the REPL:

caching is disabled (https://github.com/parcel-bundler/parcel/pull/4290)
loading babelconfig doesn't work because @babel/core excludes that logic in a browser build
custom parcelrc doesn't work (this should not be too hard to fix)
runtimes (= dynamic imports) + builtins don't work (because they read in files from node_modules via fs and in the browser, these files don't exist)

Changes made for the REPL (and not to make Parcel work) that cannot be directly upstreamed:

Plugins imports are hardcoded in packages/core/package-manager/src/NodePackageManager.js (unless you want to create a build for some specific asset types only)
the globalThis.PARCEL_...() callback in the json reporter & sourcemap visualizer are very hacky

mischnic on 6 Jul 2020

Thank you for the update! It's good to know that it's possible to tweak Parcel to work in a browser. For us, however, Parcel would be only one ingredient among others. We don't have the resources to maintain our own fork of Parcel. What we need is an existing, maintained version of Parcel that works in the browser.

DanielSWolf on 9 Jul 2020

Hey guys, just wondering how this is progressing? Is this https://github.com/parcel-bundler/parcel/projects/5 the best place to keep an eye on for updates?

danvoyce on 8 Sep 2020

👍1

I haven't worked on this since my last comment.

We don't use Github Projects (which is also why I closed that project you linked).

mischnic on 8 Sep 2020

👍2

Is there anything we can do to help?

danvoyce on 8 Sep 2020

👍2

@mischnic How could I consume this alpha version in the meantime (repl-v2)?
NPM won't let you import from a subfolder of a branch so forking it is also not really an option 😕

jfmmm on 13 Nov 2020

it's not in a state where you can simply import a package in your project
the "repl" subfolder actually contains this Preact webapp https://parcel2-repl.now.sh/, most changes to make it work in the browser were made to the actual parcel packages themselves.

mischnic on 13 Nov 2020

Was this page helpful?

0 / 5 - 0 ratings