Integration with Parcel?

[JordanMartinez]

Low priority.

Coming from this comment:

This [built-in browserify command] is a common use-case (also in my usage), and I've been thinking of providing some opinionated integration with parcel. Could you open an issue about it so we can discuss it there?

For context, I was only pointing out that spago doesn't currently have some sort of browserify-like built-in command. (I probably could have done a better job explaining that). So, this is not a request specifically for browserify.

It seems like parcel is a better option, so integrating parcel into spago sounds helpful. Still, it might be a bad idea. Since one can easily take the output of spago and push it into parcel, is this really necessary?
Without such integration, spago might be a better overall solution to dependency management when other backends are considered. (In making this statement, I don't know what other backends use to get their PureScript dependencies. However, downloading the source code via spago and allowing other backend-specific build tools (e.g. parcel) to do target-language-specific build-things seems like a good idea.)

[f-f]

Given that most of the PureScript projects I've seen end up using some kind of JS dependency and in the end need a bundler, I think some kind of integration with some bundler would be useful (the reason is "less moving parts that you have to integrate yourself")

I think there are mainly two roads here:

1. have a spago bundle-js command, that is not much more than spago build && parcel build index.html that you'd do yourself.
   I think it's OK to be opinionated and pick parcel here, in the same way pulp picks browserify
2. or go the other way around and build an integration into parcel, so that you'd do parcel build whatever, and it would compile your PS stuff automatically (through spago or any other tool the integration wants to support). I think this would be cool, and e.g. Elm has this kind of integration (PR that implemented that is here, ~500 lines of JS)

[JordanMartinez]

I think the second approach makes more sense. It'd also make things easier for those coming from the JS world. This same approach could potentially be done for other backends as well.

[hdgarrood]

I'm less keen on the second approach personally, because in my experience, most of these JS tools expect to work on one file at a time. This means that very tight integration might not work so well with PureScript, where the expectation is that whenever something changes, you rerun the compiler with all of your source files as input. I (and a few others) have found, for example, that a webpack setup which uses purs-loader is often much slower than having webpack only be aware of the JavaScript files in the compiler output directory and taking care of recompiling outside of webpack, as webpack was calling the compiler much more often than it needed to. Then again, maybe this issue won't necessarily apply to other JS bundling tools such as parcel.

[JordanMartinez]

Good point! Perhaps a better solution is to run a bash script that correctly integrates such tools together instead?

[hdgarrood]

No, Bash is often more trouble than it's worth, particularly for Windows users. I think in most cases the best approach is to point your javascript bundling tool at your purescript output directory and not build any extra integration between them.

[f-f]

It looks like this is not really in our scope anymore, so I'll close for now