Deploy website via `fluid` command-line

[rolyp]

Overview

Want to be able to import fluid as an npm package, and publish / test websites that way, instead of by bundling all of fluid, and forcing the user to download the Purescript compiler. Instead, we want to be able to build websites locally, supply them with fluid as a library, and then run them as we would expect. Currently, we are able to do this in the local project, and as an npm package, but have yet to test calling the script by using the fluid command-line tool that gets supplied to a consumer of the npm package.

Done/dropped:

• Push the current fluid functionality into a specific command, e.g. fluid eval -f [...] -d [...]
• Add a new web publishing command, e.g. fluid publish -arg1 [...] -arg2 [...]
  • Test it
    See also:
• NPM library #1036
• fluid command-line arguments via YAML config file #1018
• Command-line tool to evaluate Fluid file #1191
• Move IPCC AR6 SPM example to transparent-text authoring-assistant#25

Also:

• Building a simple command line tool with npm
• purescript-optparse ❌ package seems broken w.r.t. Node.Process

[rolyp]

Hi @ColinC-UoE:

• Clarified the tasks above: I don’t think we need to check the --global behaviour, it’s enough to know that after yarn install fluid into a fresh repo, we can yarn fluid.
• Added a link to optparse, the standard PureScript library for parsing command-line arguments. We can use this to process our single command-line argument (to make it mandatory, emit a help string, etc). Let’s go for the simplest possible thing here.

[rolyp]

Hi @ColinC-UoE. Do you want to start capturing some new subtasks above? I think it might be worth posting a question about purescript-optparse to the PureScript discourse, so let’s add that as a potential to do (we can decide later whether to bother). Then it’s probably worth experimenting with commander (although maybe do a very quick look at alternatives to check that this is the best option). There doesn’t seem to be a PureScript wrapper for commander, so we can write our own – i.e. a Commander.js and Commander.purs that exports just the method(s) we initially need, and simplifying where appropriate/feasible.

Btw, how did you get on with testing the command-line after yarn install fluid into a fresh repo?

[ColinC-UoE]

Hi @ColinC-UoE. Do you want to start capturing some new subtasks above? I think it might be worth posting a question about purescript-optparse to the PureScript discourse, so let’s add that as a potential to do (we can decide later whether to bother). Then it’s probably worth experimenting with commander (although maybe do a very quick look at alternatives to check that this is the best option). There doesn’t seem to be a PureScript wrapper for commander, so we can write our own – i.e. a Commander.js and Commander.purs that exports just the method(s) we initially need, and simplifying where appropriate/feasible.

Btw, how did you get on with testing the command-line after yarn install fluid into a fresh repo?

I've added some subtasks now.
Currently, I'm thinking the effort put into purescript-optparse is not worth the limited time left.
command-line-args is another alternative with some popularity, but more lightweight than commander. I'll try out commander first, though.
Another reason I'm leaning towards abandoning purescript-optparse is that I would want to undo all the dependency installations that are causing the compilation errors, which means I cannot properly test the command line feature after a yarn install fluid since I would need to build.

[rolyp]

I agree, purescript-optparse would only be worth pursuing if a new version of the library were released that fixed the packaging/dependencies problem.

For a pure NPM solution, yargs also looks promising.

[ColinC-UoE]

I had a look into yargs and opted for commander in the end as it appeared more straight forward to use.
After some investigation, it seems JavaScript is not made to be able to access local user files for security reasons, so I'm unsure how a user may have their .yml file be read.

[rolyp]

Ok, sounds good. Re. file loading, yes front-end Node apps (which have been bundled to run in the browser) aren’t able to access the file system. But if you’re compiling for Node itself (backend JavaScript) you should have access to the file system – I think it depends on how you build the app. (I thought just --platform=node would be enough but I don’t know much about this.)