`fluid` command-line tool

[rolyp]

N.B. When testing the hosted webpage, go to 127.0.0.1/fluid Completed/Dropped:

• [x] fluid.js hosts webpage using express or http-serve dist/article (see puppeteer.js)
• [x] May need to deploy artifact in deploy.yml or merge deploy into build.yml to ensure build data is preserved [Note: Resolved by including dist/article in NPM publish?]
• [x] NPM Upload -> Download NPM package -> Point npx http-serve to serve dist/article -> Check webpage loads
  • [x] Include dist/article when publishing to NPM
• [x] Get publish-single.sh to accept Fluid.purs located in Publish folder
• [x] Get local authorisation key to locally publish to NPM (N.B. npm login -> copy provided link into browser and log in)
• [x] Quick investigation into command line parser packages
  • Optional: Ask about issues with optparse on PureScript discourse ❌
• [x] Install fluid into fresh NPM project without global flag to check yarn fluid works
• [x] Command accepts only 1 argument
• [x] Command initially does nothing and returns via exit 0
• [x] Command accepts .yml filename as argument but does nothing with it (command format: node fluid <filename>.yml)
• [x] Command accepts .yml filename as argument and only returns 0 if file exists (otherwise reports error)

See also:

• 1036

• 1018

• Building a simple command line tool with npm
• purescript-optparse :x: 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.)

[ColinC-UoE]

Ah ha. I kept my search terms to "JavaScript ..." so none of the results mentioned Node.