I have a Yesod app that is currently serving my JS files (React), I’m trying to give a great example of why we should move to PS.
Due to the site being static each page can be seen as their own apps occasionally sharing various common components.
Right now I can just point to the .jsx file and say this is my input for this route give it to webpack and and tell it where to output it and let Yesod serve that file.
But with PS there is an extra couple of steps:
/src/File.ps --> bundle --> output/File
Then pass that file to Webpack so we can do bits and bobs to it (DCE, minimise… )
scripts/file.js with just: require("../output/File").main();
–> Webpack --> static/CompiledFile.js
Now with 40 odd routes I really don’t want to have 40 files with just requires in them!
What would be an alternative to doing it like this would you say?
@paulyoung that’s a good point, can’t recall why I didn’t use it in my last project! but think I might give that a go. We’re converting a few parts of the app that should make experimenting with this feasible.
I’ll report back probably with an example, think we’re trying to generate the entry: { } part in the webpack json file from within yesod. Should also have a kind of server side rendering of the data which we’ll populate Halogen on page load rather than initial xhr call
PureScript modules are static - they require a “runtime” which in the JavaScript backend is a file which just loads the static module and executes it. I think you can’t get away from it. You can automate this, by having a Makefile or script which creates these accompanying executor files.
Purs bundle has an option to inject that module executor line in a module, but I’m not a fan of that feature as it should be outside the scope of a bundler tool. I think the purs loader has options for using purs bundle, but idk how it works, or even if it’s desirable for your situation.
I have a few thoughts on purs-loader I’d like to drop here. As I’ve seen it used, it just enables using the webpack file watching and HMR when editing PureScript files. The problem I’ve seen with this is that it takes forever to start that webpack process if using the loader, due to it loading lots of stuff into memory. An alternative is to point webpack in watch mode at the JS output of a PureScript compilation and incrementally recompile single files using purs ide. It’s just so much simpler to maintain, IMO, but it does take a little bit longer to rebundle on change, as the entire dep tree isn’t in memory in the webpack process.
I’d like to hear more about your project - I feel like I’m shooting in the dark with this response.
FWIW we recently switched from purs-loader to just importing from the output directory into JS files if necessary.
I brought up purs-loader In spite of this since it seemed to be relevant to the original question but I wouldn’t necessarily recommend it otherwise, for the reasons mentioned above.
