The next question to consider after launching the alpha of the new Registry one year ago was “how are we going to support this in package managers?”
We briefly attempted to bolt some Registry support onto the Spago codebase, with poor results. So, after running a few small experiments to test the viability of a new implementation from scratch, we decided to sink the old Haskell codebase (now living here), and start anew with a PureScript implementation of Spago.
This is what I’m proud to announce today: Spago Next is a full rewrite of Spago, rebuilt from the ground up, in PureScript, to integrate with the new Registry from day one.
Today’s release is an “alpha”: it works well enough to be usable for day-to-day needs (we use it at work since months already) but it still has a few rough edges, and some things may change dramatically before a release that we can call “stable”.
Nonetheless, it is already available for Linux, macOS and Windows, and you can install it as follows:
npm install -g spago@next
Documentation can be found in the usual place
Quite a lot of things - let’s go through the main ones:
It’s implemented in PureScript, which will make it easier for you all to contribute!
Personally speaking I always had trouble with Haskell tooling even though I spent a lot of time with it.
PureScript’s tooling is easier to grasp, and I find myself being able to patch Spago much more quickly than it was possible with the Haskell codebase. I hope this will make it more accessible for new contributors and users alike, since any failure modes will be the ones that we are used to deal with rather than some arcane Haskell error.
Dhall has been replaced by YAML.
This is a complex issue and I’m aware that some folks will be disappointed about this.
We found two main issues with using Dhall as a config language for Spago:
- it’s an unfamiliar language, which meant that folks that were approaching PureScript for the first time - especially coming from JS - would have to learn an additional language just to make sense of the build, which is somewhat suboptimal if the goal is to have an onboarding process that is as smooth as possible
- it’s too powerful: while new users would struggle with the unfamiliar language, power users - the ones comfortable with the language - would be unable to use it to its fullest, because its power meant that Spago was supposed to deal with very complex AST-manipulation operations if we were to support even just simple “programmatic editing of your configuration”. E.g. this is how the patch for “
spago installcan work with all the Dhall files out there” looked like - it’s a lot of code because it needs to support a lot of edge cases, and we deemed this complexity unacceptable.
As of “why not TOML”: I experimented with TOML for a few months, and ended up with a terrible feeling about it. The specification is underspecified, the language is fairly verbose in the end, handling inline records is not pleasant as they all have to be on a single line, and so on. I just couldn’t come up with a schema that produced a config that was nice to look at.
So YAML it is - it’s widely used in the industry, it allows comments, and the config files are actually quite pleasant to look at! I’m aware that it’s a complicated beast, but we are parsing it so that only JSON-like things come through, so no weird things. If you are able to break out of the sandbox please open an issue or a pull request
Proper multipackage/monorepo/polyrepo support: handling multiple packages in a single repository has traditionally been a pain in PureScript, and the old Spago doesn’t really help with it.
This one should make it considerably easier - head over to the monorepo docs for more details.
Once the Registry gets out of its alpha state then it will be possible to even publish packages from this monorepo setup!
That’s right, this time Spago should be able to just publish your package - right from the command line, with no other tools required
This is all thanks to the fact that there is a lot of shared code between the Registry pipeline and Spago, so your package will run through the same checks locally before Spago hands it over to the Registry.
Solver support: the old Spago only supported a package-sets-based workflow. Again thanks to the deep Registry integration Spago is now able to offer a solver-based build plan, where you don’t have to specify a package set, and instead define version bounds for the solver to build a plan based on the packages in the Registry, truly replacing the last reason for using Bower. See the docs for more info
Any help is welcome:
- we’ll need folks to test this and to report any issues or weird things
- and if you feel like contributing with code that’s even more lovely - there are still a few things missing so any additional pair of hands is a blessing. We keep a list of tickets that are up for grabs for new contributors. Don’t hesitate to ask for clarifications if you’d like to work on one and it’s unclear and/or poorly specified
For a while, a few months at least, or until we work through the known bugs for the alpha release - whichever is longer