Idea: Separate `purs compile` flags somehow

[googleson78]

What do you think about separating flags passed to purs compile explicitly in some way, for example with --purs-compile-flags=?

Right now --help says you should use -- if you want to specify that something should go to purs compile, but what really confused me is that it is not mandatory to separate them with --.
Running spago build src/X.purs src/Y.purs works fine - which is not immediately obvious when looking at spago build --help (it has no mentions of files as arguments).

This was especially problematic when I tried spago build --watch --path src/**/*.purs, only to see how not all of my files were "being watched". In reality only the first file from the expanded glob is being watched, because --path accepts only one file - the rest are passed onto purs compile, allowing compilation to proceed without errors (or at least that's what I think is going on here).

[f-f]

Yeah this sounds like not the ideal behaviour. I'd say we'd want to keep the -- thing instead of adding this to a flag, but I wonder if we can enforce it somehow? (My optparse-applicative-fu is not good enough to answer this)

This is the code for the passthrough stuff:
https://github.com/spacchetti/spago/blob/2d349cc7c1ce02769688e136bdf9a3939c04ed35/app/Spago.hs#L168

[googleson78]

According to man bash (on my machine) the semantics of -- is "there will be no more options" (as in "strings that start with a dash are now treated as normal arguments").

optparse-applicative docs also match this - it treats everything after -- as an argument.

However, parsers always accept a special argument: --.
When a -- is found on the command line, all the following words are
considered by argument parsers, regardless of whether they start with - or not.

To me it seems like we can't (and possibly shouldn't) force these arguments to be passed after the --.

It would be possible to use noIntersperse forcing all arguments to be at the end, but to me this is a greater cost to UX, compared to adding an option.
It would also still be quite confusing when paired with --path at the end (not resolving my original case).

[f-f]

@googleson78 great points. We already have the behaviour you suggest in your first post for the node arguments, so introducing it for purs arguments too wouldn't be a too big deal, if we "absorb" into spago interface the most common ones (e.g. as we do for spago docs --format)