Integrate PSA into spago

[JordanMartinez]

Description of the change

Fixes #904.

• for later PRs, determine what additional features to support and which get spago.yml support (see https://github.com/natefaubion/purescript-psa-utils/pulls and https://github.com/natefaubion/purescript-psa/issues)

Summary of PR:

1. psa and psa-utils were vendored into this codebase and modified/updated in the following ways:
   • using Dodo as its printer rather than its custom code. Moreover, a brighter red and yellow are used for warnings and errors than what was used previously.
   • using codec-argonaut as its Json encoder/decoder
   • removing unused/unexported declarations
   • replacing some declarations with pre-existing ones (e.g. replicate with power
   • cleaning up the imports
   • renaming PsaOptions to PsaOutputOptions because *Options in this codebase typically refers to values used in misc commands.
   • renaming output to buildOutput because output is already exported from Spago.Prelude
   • combining stash and stashFile into one argument
   • renaming the ansi arg to color (since Spago already has a similarly-named flag)
   • dropping the isLib arg as libraries can be determined via Spago
   • changing the Json printer to print to stdout rather than stderr. (I'm not sure if this is correct to do, but I'll clarify why in the PR via a code comment).
2. psa was integrated into Spago in the following way:
   • logic in psa's main function was extracted out into Psa.psaCompile, which wraps Purs.compile
   • various logDebug statements were added to make it easier to see where problems arise (if any) in the future
   • Of the args that psa takes, I decided to keep all of them configurable via spago.yml except for:
     • json-errors: I assume this is only useful if being called by an IDE or if someone wants to run their own custom printer
     • ansi: this doesn't seem like something one should configure via spago.yml, only via CLI
     • libraryDirs: with Spago in control, we know what the library directories are.
   • Stashes are stored in one of three places:
     • when spago build -b pkgName is used: .spago/stashes/defaults/pkgName.stash
     • when spago build is used: .spago/stashes/defaults/entire-workspace.stash
     • when spago build --psa-stash-file "foo" is used: .spago/stashes/custom/foo.stash
     • when spago build --psa-stash-file "../foo" is used: .spago/stashes/custom/foo.stash

Checklist:

• Added the change to the "Unreleased" section of the changelog
• Added some example of the new feature to the README
• Added a test for the contribution (if applicable)

P.S.: the above checks are not compulsory to get a change merged, so you may skip them. However, taking care of them will result in less work for the maintainers and will be much appreciated 😊

[f-f]

Thanks Nate! If you have no preference on this then my personal preference is that we stick to this fork here so we can iterate quickly on the new Spago. Once things get more stable we can think about upstreaming improvements to your repo.

[JordanMartinez]

As I've spent time on this, I'm actually wondering why this work isn't being done in the compiler itself as that would remove the underlying reason for why psa even exists. And then, this work wouldn't even be necessary and the IDE wouldn't need to depend on psa either. Thoughts?

[f-f]

@JordanMartinez indeed it would be nice if the compiler did all of this and psa would not have reason to exist - however the issue is not straightforward, so (as the linked thread shows) I am of the opinion that we'd be better off getting this to work in Spago first, and then eventually deprecate this functionality once the relevant things are merged in the compiler.

[f-f]

I see - these are fair points and they all makes sense but I'm still concerned about having the "build options" all scattered around the different config files.
I think the clarity of having only a single set of things to configure is a bigger advantage over being able to issue small tweaks to the different packages in the build.

It sounds like we can cover most of these concerns by having some more configuration flags for test code, and compiling that separately with different settings if these are specified.
The only thing that we'd not cover would be the "test code as package code" scenario of halogen-hooks, but I'd say it's acceptable, since it's a very niche use-case. If it becomes more common, then we can consider a way to support it.

[f-f]

Suggested change

	ArgParser.argument [ "---censor-build-warnings" ]
	ArgParser.argument [ "--censor-build-warnings" ]

These flags now all have three hyphens

[f-f]

This is about the user being able to configure the build via flags. I don't think calling spago publish --strict makes much sense, but of course we can pick up the strict flag from the config file if specified.

[f-f]

I left a comment in the previous review and I can't find it - I don't see the benefit of allowing custom stash files, since we already differentiate the stash locations per package in the build, so this just adds more complexity for no clear upside

[f-f]

I'd add that this is a fairly weak opinion because we don't have any real-world usage of this whole monorepo setup yet.
We can probably just ship the "workspace-only" version and then tweak later once folks need things.
I'd likely prefer the "workspace settings are the default ones, and package specific ones override" implementation, so we'd have to rework this anyways.

[f-f]

I'll merge this now - thanks Jordan!