Parcel support for Purescript assets

I’m a late-comer to this Parcel stuff, quite impressed by how much it lives up to the “zero-config” promise. It seems like it would be an easy win for Purescript to be included in the bundle of asset types that are supported by it.

Given all the excellent work on psc-package sets, Spago, etc i’m wondering whether the reason that this hasn’t been done already is due to resource constraints (very well aware of them!) or some lack of agreement on one single, canonical way to generate code and resolve the modules.

In case it’s the latter, i thought i’d try and solicit discussion here…

1 Like

Digging into what it would take to add Purescript support i see that they are well down the road towards a Parcel 2.0. So the first conclusion i have is that it would be better to target that release.

Here’s their architecture doc for the release: https://github.com/parcel-bundler/parcel/blob/master/PARCEL_2_RFC.md

A sort of hacky way of using Purescript with Parcel:

or some lack of agreement on one single, canonical way to generate code and resolve the modules.

I think this is it. There are loads and loads of factors which factor into how people want to set their front end build processes up. It’s difficult for me to imagine there being agreement on one single canonical way of processing and/or bundling code in the PureScript community without there first being agreement for the same thing in the JavaScript community, and I think that’s very unlikely to happen any time soon.

Since you brought it up, I’ll note that we already have an issue open in Spago to discuss a possible Parcel integration: https://github.com/spacchetti/spago/issues/134 (and as a Spago+Parcel user I’d really love to see it happening)

1 Like

oh, neat, i had either missed that or forgotten about it

Can’t disagree with premise at all. But it’s still potentially nice experience for someone to get, say, an equivalent experience to trying out “hello sailor!” in Pulp when they’re using Parcel.

I definitely see a lot of value in being in the list on the side-bar on the Parcel documentation as a peer of Elm (https://parceljs.org/elm.html) and TypeScript.

I should perhaps be very clear here - i’m only talking about making Purescript more inviting to try for Parcel users not in any sense suggesting that Purescript should use Parcel as a default or anything.

Ah okay, sure - so you’re saying we want there to be a canonical approach for people who have already decided that they want to use PureScript with Parcel? Then I misunderstood; I agree that would be a good thing to work towards.

As a general suggestion, lots of us have had the most success when we don’t try to make our JavaScript bundling tools aware of PureScript (other than perhaps telling them that they should run purs compile "src/**/*.purs" "bower_components/*/src/**/*.purs" whenever a PureScript source file or PureScript ffi file changes), and then pointing them at the PureScript output directory.