Spacchetti-CLI is now Spago

[justinwoo]

https://github.com/JordanMartinez/purescript-jordans-reference/blob/0f9ace0b6a50b2a690294a0c8984f10e958763b4/01-Build-Tools/01-Tool-Comparisons/01-Dependency-Managers.md

https://github.com/spacchetti/spago/releases/tag/0.6.0.0

[JordanMartinez]

Nice!

On the downside, this doesn't work for Windows users yet (and I'm not one of those either, haha). I'm not sure whether this should migrate. If I don't, that's annoying because this is a better workflow. If I do, then that creates other problems. Maybe this repo will force someone to open such an issue and maintain it?

[JordanMartinez]

I'm posting the twitter announcement here for context:
https://twitter.com/fabferrai/status/1074257977815785477?s=19

[justinwoo]

I guess Spacchetti never supported Windows either though (unless you built it yourself)

[JordanMartinez]

Haha! Didn't know that. Well, that resolves that dilemma.

[JordanMartinez]

Sorry it's taken so long to get to this. Spago looks really mature now. I'll be focusing on this more in the next few weeks.

[f-f]

@JordanMartinez from the 0.7 release of some days ago, the NPM package also works for Windows (we had Windows builds since the previous release though)

[JordanMartinez]

Nice!

My current focus this week has been working on the documentation discussion work with Alex/chexxor

Still, the work this will entail has a few parts

Simple to:

• update all psc-package commands to use spago
• update CI to use spago
• update install guide to use spago

Longer to do:

• explain the differences of spago and bower (and why both are currently needed). Specifically, I mean improving the table that compares bower and psc-package. I will be replacing psc-package with spago because I see the latter tool as being superior to the former one.
• update psc-package's 'how it works' flowchart to show how one modifies the 'official' package set
• overview spago's commands (update the mindmap that exhaustively shows commands and all arguments)
• create a new file called "History of PS' Dependency Managers" that explains how we got to this current state.
• update 'project from start to finish' file to use spago instead of psc-package
• update the for-each--install-deps-and-compile.sh to use spago instead of psc-package
• write another Bash script that will migrate entire project from psc-package to spago

Release Notes:

• Notify people that they need to update the ide-purescript Atom package to be able to configure the IDE to work with spago

Also, this will be considered a major breaking change because we're switching dependency managers (besides renaming files and whatnot).

I know you two have written a ReadMe that explains spago well (haven't looked into it that much but have skimmed parts of it). So, some of this work may not be needed. I won't know until I start.

[JordanMartinez]

I'm actually wondering whether this should be included yet. This project uses Atom, so if it doesn't work out well with that, it will be a major issue for me as I continue to develop this and for others who are using this to learn.

Also, I realize that there is no corresponding spago docs command yet.

[f-f]

@JordanMartinez I was planning to take on the implementation of spago docs later this week

Re Atom support: all issues are fixed in both projects, AFAIK we're just missing a release now that 0.25 has been released we should be good on that 🎉

[JordanMartinez]

now that 0.25 has been released we should be good on that 🎉

Yup! Just saw the update :-D

As for the docs issue, I only refer to it once in this project. I believe it can be reimplemented by passing the necessary arguments to purs directly.
In other words, it's not a show stopper.

[JordanMartinez]

@f-f Does my new History: How We Got Here section fairly summarize the current state in a way that's understandable to new people?

I'm assuming that spacchetti and purp are 'deprecated' / no longer things that need to be used / should be migrated away from and towards spago.

[justinwoo]

there's no reason to keep using spacchetti now but purp is something i use actively, i just don't talk very much about it

[f-f]

@justinwoo I think what Jordan means here is "deprecated" as in "should we not suggest it to people". In this sense purp effectively is, because:

• as you said, you don't want to advertise it
• its functions are a strict subset of spago's

@JordanMartinez looks great! I'll add some clarifications:

• in general I'd skip mentioning purp, as it has little role in this - if the audience is newcomers they don't need this granular level of detail, it's enough to know that from the spacchetti experiment we spawned spago
• it's unclear if you're talking about "spacchetti" the package set or "spacchetti-cli" the CLI that helped to do things with that package set (that later became spago)
• in the last diagram there's an arrow from spago to psc-package, but spago never calls psc-package (i.e. is basically a reimplementation), so I'd remove that arrow.
  There are some commands that can help you setup psc-package projects, but IMHO now they are there only for backwards compatibility (I can expand on this if you wish)

[JordanMartinez]

I think what Jordan means here is "deprecated" as in "should we not suggest it to people". In this sense purp effectively is, because:

Yeah, that was my point.

in general I'd skip mentioning purp, as it has little role in this - if the audience is newcomers they don't need this granular level of detail, it's enough to know that from the spacchetti experiment we spawned spago

I agree.

it's unclear if you're talking about "spacchetti" the package set or "spacchetti-cli" the CLI that helped to do things with that package set (that later became spago)

I believe I was talking about spacchetti-cli.

in the last diagram there's an arrow from spago to psc-package, but spago never calls psc-package (i.e. is basically a reimplementation), so I'd remove that arrow.
There are some commands that can help you setup psc-package projects, but IMHO now they are there only for backwards compatibility (I can expand on this if you wish)

Gotcha. I guess I was trying to show that spago "uses" the psc-package under the hood (similar to how pulp "uses" bower`) for dependency management.

Looks like I'll need to rethink how I explain this.

[JordanMartinez]

Here's an update on my work:

• Phase 2 and its following flowcharts have been updated to remove purp from the story and show that psc-package and spacchetti were "absorbed" into spago. Is this a good explanation/summary for people unfamiliar to the situation?
• The Spago Explained.md file has been updated. Focus in particular on the "how it works" flowchart.

Also, I'm not yet familiar with parcel. This migration is making me learn more about that.

Questions I have:

• Is the workflow in the "how it works" flowchart and "Spago--from-start-to-finish" files correct? Have I put the steps into the right order?
• I can run the output of spago bundle via node, but this does not include DCE. To get DCE, I need to use spago make-module. What do I need to do to get the output of spago make-module to be runnable via node? I know I need to make it include a call to Main.main();. Is there an easy way to do this?
• There is no watch command. What program do you recommend I use as a workaround until this is implemented? parcel watch? Nevermind, I actually read through that corresponding Spago issue and saw what was recommended.
• There is no run command. Are there any plans to add such a command or an option to an existing command (so it works similar to pulp run -m Main -- "value")?

Possible communication issues I have found:

• the explanation for the freeze command doesn't indicate that this is an important security feature that should always be used. Rather, it seems like a 'nice thing to do sometimes' based on its documentation when I run spago freeze --help. Reading through the Dhall wiki page that mentions this clarifies why this is so important. I realize you explain this in Spago's ReadMe, but it might be a good idea to explain it in the outputted help as well.
• spago build --help states that "any PURS options are passed through." Great, but to which PureScript command are those options passed? I'm assuming its purs compile. For comparison, pulp indicates this, so I know which options I can use.

[f-f]

@JordanMartinez reading through your links I figured that some of the spago issues you found are low-hanging-fruits, so I thought we might as well fix them:

• about the weird freeze command: since it's actually unconvenient to not have hashes, spago should just add them automatically, fix up in Always ensure that the package-set has a hash on it purescript/spago#128
• about spago not stating which purs command the options refer to: fix up in Document some common issues purescript/spago#125
• about the watch flag: fix up in Add --watch flag to build and test commands purescript/spago#126
• about the docs command: fix up in Add first implementation of the spago docs command purescript/spago#127

To answer the rest of your questions (and the other concerns in the "Problem points" section:

show that psc-package and spacchetti were "absorbed" into spago

It is correct that spacchetti-cli was absorbed into spago (though I'd say it "evolved"!).
However, I wouldn't say the same about psc-package. Some of its functions are the same as spago's, but this is true also for pulp for example.
At this point psc-package is considered "stable", but it is still maintained - in fact, many people use it and have no reason to switch (all of this could change in the future, but this is the current status).

Makes sense?

Is the workflow in the "how it works" flowchart and "Spago--from-start-to-finish" files correct?

Some clarifications about it:

• point 2b: spago doesn't re-verify the package-set, it trusts that upstream's CI has verified it
• point 2a: "freezing" (in this case is more like "hash protection check", since "freezing" is the act of adding hashes to an expression) happens before the package-set is patched locally

I'll also note that there's no technical issue against having a local global cache of packages, it's just that no one opened an issue about it yet 😄 (so please open one if you think it's a good thing to have)

I can run the output of spago bundle via node, but this does not include DCE. To get DCE, I need to use spago make-module. What do I need to do to get the output of spago make-module to be runnable via node? I know I need to make it include a call to Main.main();. Is there an easy way to do this?

spago bundle does include DCE. In fact, make-module is nothing more than doing the bundle and then adding a line of js exporting the Main module, see the source for both here

So if you wish to "make a module and run it via node", that's just spago bundle.

If there's a place in our docs that it's misleading about it, it would be lovely if you could open a PR to clarify it somehow :)

There is no run command

I never had a use-case myself for this (as I don't use PS on node). If you think this is a common use-case could you open an issue about it?

There is no built-in browserify command

This is a common use-case (also in my usage), and I've been thinking of providing some opinionated integration with parcel. Could you open an issue about it so we can discuss it there?

You cannot use this workflow to develop libraries

You can use spago to develop libraries, the only part that require you to use pulp and bower are versioning and publishing on bower. The reasons why this is required are stated here.
In general you'll have a bower file, but it's only necessary that it contains the right list of dependencies, the version can be * (at least for adding it to the package set).
Basically all of this can be automated, and this would mean having spago version and spago publish

[JordanMartinez]

• about the weird freeze command: since it's actually unconvenient to not have hashes, spago should just add them automatically, fix up in Always ensure that the package-set has a hash on it purescript/spago#128
• about spago not stating which purs command the options refer to: fix up in Document some common issues purescript/spago#125
• about the watch flag: fix up in Add --watch flag to build and test commands purescript/spago#126
• about the docs command: fix up in Add first implementation of the spago docs command purescript/spago#127

Thanks for taking care of those things!

It is correct that spacchetti-cli was absorbed into spago (though I'd say it "evolved"!).
However, I wouldn't say the same about psc-package. Some of its functions are the same as spago's, but this is true also for pulp for example.
At this point psc-package is considered "stable", but it is still maintained - in fact, many people use it and have no reason to switch (all of this could change in the future, but this is the current status).

Makes sense?

Yeah. Thanks for the clarification. I think my goal was to make spago seem like the more obvious/only DM solution besides bower to limit people's choices. Too many choices leads to decision paralysis. Personally, I feel like spago is going to replace psc-package, but that might be due to not knowing more about their differences.
The other concern was how to communicate an idea using a picture. The arrows could show "uses/wraps" some other thing. Or it could mean "the ideas of X are now included in Y." Looks like I may be trying to do too much in one picture. On another hand, the photo does not include some of the other build tools that people use.

spago bundle does include DCE. In fact, make-module is nothing more than doing the bundle and then adding a line of js exporting the Main module, see the source for both here
So if you wish to "make a module and run it via node", that's just spago bundle.
If there's a place in our docs that it's misleading about it, it would be lovely if you could open a PR to clarify it somehow :)

I've opened an issue first describing the issue and why I misunderstood things (see purescript/spago#135) and then submit a PR.

I never had a use-case myself for this [built-in run command] (as I don't use PS on node). If you think this is a common use-case could you open an issue about it?

I think Justin's already done that via purescript/spago#131

This [built-in browserify command] is a common use-case (also in my usage), and I've been thinking of providing some opinionated integration with parcel. Could you open an issue about it so we can discuss it there?

Done. See purescript/spago#134

You can use spago to develop libraries, the only part that require you to use pulp and bower are versioning and publishing on bower. The reasons why this is required are stated here.
In general you'll have a bower file, but it's only necessary that it contains the right list of dependencies, the version can be * (at least for adding it to the package set).
Basically all of this can be automated, and this would mean having spago version and spago publish

Perhaps I should clarify that statement. The point is that you can't publish docs to Pursuit unless you are using bower at some point. While it may be possible to use spago to create libraries, I'm not sure whether that would be a good idea because I could "patch" a dependency in my package set before doing that and potentially break expectations.
So, perhaps that could work but only if the package set did not include any overrides or additions?
Do you want me to open an issue to discuss/clarify this more?

[JordanMartinez]

Summary of below content

I'm going to have to exclude this issue from the next major release (#291). It's slowed me down and there are other low-hanging fruit I can address now rather than continue waiting for things to improve.

Keep in mind that my repo's folders' build configurations are definitely outside the norm. pulp can handle these configurations well, but spago currently does not. I imagine that fixing them in spago will require a breaking change. If spago wants to draw more people to it, it might help to duplicate some of pulp's configuration settings where it makes sense to make such a migration easier because the only difference that would change is typing spago instead of pulp.

Please don't misunderstand me. I think spago is a good tool and still plan to migrate to it in the future. However, it's not something I'd want to use in this project right now. psc-package still works for me (though I don't know for how much longer).

Let me know which of these I should open issues for in spago.

Syntax - Basic Syntax

Things I did

Called spago init which migrated to a spago package.

The below directories were not deleted. I think that's fine since one will likely only "migrate" a project once. Removing these aren't hard, which is what I did:

• .psc-package
• .psci_modules
• .pulp-cache
• output

Tried to compile the project again and see what issues arise.

Failing to compile the project without a "Main" module

$ spago build
Installing 6 dependencies.
Installation complete.
Error found:
in module Test.Main
at test/Main.purs:8:1 - 8:20 (line 8, column 1 - line 8, column 20)

  Module Main was not found.
  Make sure the source file exists, and that it has been provided as an input to the compiler.


See https://github.com/purescript/documentation/blob/master/errors/ModuleNotFound.md for more information,
or to contribute content related to this error.


spago: Failed to build.

Right, because there isn't supposed to be a Main module. I'm just trying to see whether the entire project can compile. So let's look at the build command's options and see what we can do

$ spago build --help
Usage: spago build [-j|--jobs JOBS] [-p|--path PATH] [ ..ANY `PURS` OPTION]
  Install the dependencies and compile the current package

Available options:
  -j,--jobs JOBS           Limit the amount of jobs that can run concurrently
  -p,--path PATH           Source path to include
   ..ANY `PURS` OPTION     Options passed through to `purs`; use -- to separate
  -h,--help                Show this help text

Let's try removing the path completely

$ spago build -p ""
Installing 6 dependencies.
Installation complete.
purs: /home/jordan/purescript-reference/11-Syntax/01-Basic-Syntax/: openBinaryFile: inappropriate type (is a directory)
spago: Failed to build.

That's not too surprising. Why don't we try a real path that is commonly used?

$ spago build -p "src/**/*.purs"
Installing 6 dependencies.
Installation complete.
Error 1 of 33:

  at src/02-Data-and-Functions/07-Some-Keywords-and-Their-Syntax/03-Keywords--Case-expression-of.purs:1:1 - 104:18 (line 1, column 1 - line 104, column 18)

    Module Keyword.CaseOf has been defined multiple times


  See https://github.com/purescript/documentation/blob/master/errors/DuplicateModule.md for more information,
  or to contribute content related to this error.

Hmm... "Duplicate Module" is an odd error to get. So, it doesn't quite work if I'm just designing a "library" of sorts like this. Perhaps we should try a different command?

$ spago --help
Spago - manage your PureScript projects

... things ommitted here...

Available commands:
  ...
  build                    Install the dependencies and compile the current package
  repl                     Start a REPL
  test                     Test the project with some module, default Test.Main
  bundle                   Bundle the project, with optional main and target path arguments
  make-module              Bundle a module into a CommonJS module
  ...

Does REPL work?

$ spago repl
Error found:
in module Test.Main
at test/Main.purs:8:1 - 8:20 (line 8, column 1 - line 8, column 20)

  Module Main was not found.
  Make sure the source file exists, and that it has been provided as an input to the compiler.


See https://github.com/purescript/documentation/blob/master/errors/ModuleNotFound.md for more information,
or to contribute content related to this error.


spago: callProcess: purs "repl" ".spago/console/v4.2.0/src/**/*.purs" ".spago/effect/v2.0.1/src/**/*.purs" ".spago/newtype/v3.0.0/src/**/*.purs" ".spago/partial/v2.0.0/src/**/*.purs" ".spago/prelude/v4.1.0/src/**/*.purs" ".spago/psci-support/v4.0.0/src/**/*.purs" "src/**/*.purs" "test/**/*.purs" (exit 1): failed

Seems like the same issue as before. Let's try bundle.

$ spago bundle
purs bundle: No input files.
spago: Bundle failed.

Any options that fix this issue?

$ spago bundle --help
Usage: spago bundle [-m|--main MAIN] [-t|--to TO]
  Bundle the project, with optional main and target path arguments

Available options:
  -m,--main MAIN           The main module to bundle
  -t,--to TO               The target file path
  -h,--help                Show this help text

Looks like no. Since make-module wraps the output of bundle, it won't help either.

Hello World - Hello World and Effects

Things I did

Called spago init which migrated to a spago package. (same situation as before)

Tried to compile the project again and ran into more issues with "there is no Main module"

$ spago build
Installing 38 dependencies.
Installing (and.... 38 dependencies were listed here)
Installation complete.
Error found:
in module Test.Main
at test/Main.purs:8:1 - 8:20 (line 8, column 1 - line 8, column 20)

  Module Main was not found.
  Make sure the source file exists, and that it has been provided as an input to the compiler.


See https://github.com/purescript/documentation/blob/master/errors/ModuleNotFound.md for more information,
or to contribute content related to this error.


spago: Failed to build.

Silly me, I should have defined the actual module name to my "Main" program (since there are a couple of ones there to provide easily runnable examples).

$ spago build -m HelloWorld
Invalid option `-m'

(help text gets printed here)

Oh right, there is no --main argument in build. Why not try a command that does have that?

$ spago bundle -m HelloWorld
purs bundle: No input files.
spago: Bundle failed.

Uh.... ok.... What does the help say? Is there a path argument that I need to provide?

$ spago bundle --help
Usage: spago bundle [-m|--main MAIN] [-t|--to TO]
  Bundle the project, with optional main and target path arguments

Available options:
  -m,--main MAIN           The main module to bundle
  -t,--to TO               The target file path
  -h,--help                Show this help text

Ok.... Looks like at this point, I would just have to "drop down" to using purs directly. Definitely not desirable.

[f-f]

@JordanMartinez I don't think taking care of these errors you encountered would require a breaking change. I'll try to clarify them:

• spago init creates configurations and tries to create src/Main.ps and test/Main.ps. It doesn't delete anything, as picking things to delete is Very Hard (all of this is stated in the README somewhere, but maybe it's not clear enough there)
• "Failing to compile the project without a "Main" module" → if you notice in the error the compiler gives you, there's a Test.Main module that tries to import the Main module. Deleting the Test.Main module fixes the error.
  Here the problem is that spago init in your case created only the test/Main.ps file (as src was there already), and that that file imports the Main module (which you don't have). This should be fixed in spago init. Possible solutions:
  • Create either both of the template files or none of them
  • Stop importing Main from Test.Main
• spago build -p "" → This doesn't "reset" the path, it adds an empty path to the default ones (which are "src/**/*.purs" and "test/**/*.purs"). The empty path could be checked for, so the user doesn't get this cryptic error
• spago build -p "src/**/*.purs" → as mentioned above, there are two default paths included, and this is one of them. All the paths are just passed to purs, that gives you back the "duplicate module" in this case. We could of course make a set of all the paths, but comparing globs is really hard, so we cannot exclude the duplicate path problem. Maybe a good solution would be to print the purs command that is being called?
• spago bundle fails because your build fails and output is empty. The rule of thumb is "if spago build fails, then nothing else can work"
• passing a "main module" option to build wouldn't make sense, as we just give the paths to purs and it will compile all the "module tree". There's no starting module as purs will figure it out

Is this of any help?

[f-f]

@JordanMartinez

Yeah. Thanks for the clarification. I think my goal was to make spago seem like the more obvious/only DM solution besides bower to limit people's choices. Too many choices leads to decision paralysis. Personally, I feel like spago is going to replace psc-package, but that might be due to not knowing more about their differences.

You can still list psc-package, but not recommend it (as spago is strictly a superset feature-wise)

The other concern was how to communicate an idea using a picture. The arrows could show "uses/wraps" some other thing. Or it could mean "the ideas of X are now included in Y." Looks like I may be trying to do too much in one picture. On another hand, the photo does not include some of the other build tools that people use.

I think the arrows are well suited for showing "this uses/wraps that", while "ideas inclusion" is better represented by prose (as you don't have a binary state arrow/no-arrow, things are usually more complicated)

I've opened an issue first describing the issue and why I misunderstood things (see purescript/spago#135) and then submit a PR.

Done. See purescript/spago#134

Thanks!

Perhaps I should clarify that statement. The point is that you can't publish docs to Pursuit unless you are using bower at some point. While it may be possible to use spago to create libraries, I'm not sure whether that would be a good idea because I could "patch" a dependency in my package set before doing that and potentially break expectations.
So, perhaps that could work but only if the package set did not include any overrides or additions?
Do you want me to open an issue to discuss/clarify this more?

Let's have an issue to discuss it! It's likely worth adding a FAQ entry or a separate section for this

[JordanMartinez]

if you notice in the error the compiler gives you, there's a Test.Main module that tries to import the Main module. Deleting the Test.Main module fixes the error.

🤣 I'm a terrible programmer, haha! I skimmed the error message and thought it was referring to something else. I didn't realize the error was arising due to a test source file. 🤦‍♂️ Sadly, this is not the first time this has happened in my PS journey. You'd think I'd have learned by now.

Here the problem is that spago init in your case created only the test/Main.ps file (as src was there already), and that that file imports the Main module (which you don't have). This should be fixed in spago init. Possible solutions:

• Create either both of the template files or none of them
• Stop importing Main from Test.Main

Hmm.... this kind of falls under the issue of using one command to do multiple things at once (initialize a project and migrate from psc-package projects). I know you want to keep the number of commands low and when spago fully replaces psc-package, a migration command won't be needed. So, I think the second option makes more sense as the current implementation assumes that a project will always have a Main module. Also, I like a buildTool init command that generates my project structure for me. If I have to manually create the test directory and then the Test.Main module file, it would not be desirable.
Another option is to just add a 'migration' FAQ section and note what will occur if one does this and how to fix such situations like this.

spago init creates configurations and tries to create src/Main.ps and test/Main.ps. It doesn't delete anything, as picking things to delete is Very Hard (all of this is stated in the README somewhere, but maybe it's not clear enough there)

This wasn't an issue and I hope it did not come across as one. I was merely documenting what occurred when I did this. (It was to help me know how to write the "migrate-to-spago.sh" file as I could delete these unneeded files in my repo after setting up the corresponding spago project)

spago build -p "src/**/*.purs" → as mentioned above, there are two default paths included, and this is one of them. All the paths are just passed to purs, that gives you back the "duplicate module" in this case. We could of course make a set of all the paths, but comparing globs is really hard, so we cannot exclude the duplicate path problem. Maybe a good solution would be to print the purs command that is being called?

I think this is a result of human error, not a bad program design. Perhaps it could be documented better by indicating the source globs (your last comment's idea). Perhaps the command docs in spago could clarify this as well.

The rule of thumb is "if spago build fails, then nothing else can work"

Another thing to include in an FAQ section / general knowledge / migration section?

You can still list psc-package, but not recommend it (as spago is strictly a superset feature-wise)
...
I think the arrows are well suited for showing "this uses/wraps that", while "ideas inclusion" is better represented by prose (as you don't have a binary state arrow/no-arrow, things are usually more complicated)

Good points!

Let's have an issue to discuss it! It's likely worth adding a FAQ entry or a separate section for this

Done. See purescript/spago#142

[f-f]

Hmm.... this kind of falls under the issue of using one command to do multiple things at once (initialize a project and migrate from psc-package projects). I know you want to keep the number of commands low and when spago fully replaces psc-package, a migration command won't be needed. So, I think the second option makes more sense as the current implementation assumes that a project will always have a Main module. Also, I like a buildTool init command that generates my project structure for me. If I have to manually create the test directory and then the Test.Main module file, it would not be desirable.

I think this is a result of human error, not a bad program design. Perhaps it could be documented better by indicating the source globs (your last comment's idea). Perhaps the command docs in spago could clarify this as well.

Good points, I'll go with these solutions

Another thing to include in an FAQ section / general knowledge / migration section?

I documented this here, but reading it out loud I feel like it would make sense to just run build as part of these other commands..

(this would create other issues though, like carrying over all the build flags to these commands too. UX is hard)

Done. See purescript/spago#142

Thanks!

[JordanMartinez]

I documented this here, but reading it out loud I feel like it would make sense to just run build as part of these other commands..

(this would create other issues though, like carrying over all the build flags to these commands too. UX is hard)

Just leave it as is then. spago is still maturing, so part of the issue is that people aren't familiar with it yet. I think pulp does pass through the build flags to other commands and it's what makes it complicated to understand at times. For example, see the build tools mindmap of pulp (Right click the image and click "View Image" to see it more clearly)

[JordanMartinez]

Latest update on this. I've updated #291 to use spago with the latest release you made and it seems to be working just fine 🎉

It took a while to figure out how parcel works, but I think I'm getting the hang of it.