Remove dependencies on webpack, purs-loader

[hdgarrood]

When you run pulp server, webpack calls purs-loader to compile PureScript files, and purs-loader might be using different options to the ones pulp would be using. In particular, purs-loader uses the --require-path=../ option when it calls psc: https://github.com/ethul/purs-loader/issues/15

This is problematic because you could end up with a mixture of files compiled with the different sets of options. In particular, using --require-path=../ seems to be incompatible with psc-bundle.

purs-loader also writes a .psci file, which can cause problems, because of how pulp tries to preserve commands other than :load commands, but:

• :m[odule] is an alias for :load,
• pulp doesn't recognise this,
• purs-loader uses :m in the .psci file it writes.

It's not immediately clear to me how this should be addressed. Perhaps we could make the output directory for pulp server non-configurable, and use an unlikely name, like .pulp-server-output? That still leaves the psci issue, though.

[megamaddu]

psc-ide-server also uses the output folder for its suggestions. Currently it might result in strange psc-ide behavior for someone relying on pulp server to do their rebuilds, and if pulp server used .pulp-server-output it wouldn't work at all. It's also common in Atom to have the build extension run pulp build when a file is saved, which would result in even stranger conflicts as the output folder flips back and forth from pulp build content to pulp server content, potentially on per-file basis.

Not an answer, just more to consider 🙂

[hdgarrood]

Hm, true. How about getting rid of the webpack dependency entirely, and building pulp server on top of a simpler package like, say,serve, or maybe even the purescript-node http bindings, together with the existing watching stuff that pulp -w uses? We could use an AVar to deal with the case where a request is received during recompilation, too, and I think that would be fairly straightforward.

[ttbodil]

I'd certainly consider a PR for that. :)

[hdgarrood]

Cool. :) Do you know what webpack does if you request something while it's being recompiled, by the way? My first guess for sensible behaviour would be to wait for a few seconds (in case it's nearly done), and if it doesn't finish in that time, return a 503.

[ttbodil]

Webpack won't serve anything while it's recompiling, just deferring responses until it's done. Because it's a development tool, you don't want it throwing timeout errors, you really do want it to finish up and either succeed with a response or deliver a suitable error response. What Webpack does is actually to collect the compilation errors and deliver them bundled up into a web page that sends them to console.error.

[hdgarrood]

Ok, that does seem more sensible.

[megamaddu]

This sounds great, and one of the few things here that could be within reach for me to work on.

[ethul]

If it helps, the purs-loader 0.5 no longer writes a .psci file. It may be added to the purescript-webpack-plugin, but we could potentially include a switch to control if it writes the file or not.

[hdgarrood]

That's good to know, thanks :) I think I still like the "swap out Webpack for serve or something similar" approach better - it seems much more in line with Pulp's philosophy. I'm not sure Pulp and Webpack are philosophically compatible with each other, really.

[hdgarrood]

Or, perhaps more convincingly, if we use the same mechanism in pulp build as we do in pulp server, then we don't need to ever worry about these diverging in the future.