Top down PS#2
Open
joneshf wants to merge 7 commits into
Open
Conversation
`node_modules` are development dependencies that differ per platform. In particular, the committed files are for a Windows machine. They don't work for a Linux machine. Having them committed means developing on a different platform requires: 1. Deleting the committed files. 2. Installing the dependencies. 3. Remembering not to commit anything in the `node_modules` directory. We can make it a smidge easier by untracking these files. The workflow on all platforms becomes: 1. Install the dependencies.
I don't know if this is cross-platform. Hopefully, whatever doesn't work on Windows can be a small fix. The idea isn't to write-off Windows nor make it second class, more to track the dependency graph of the project explicitly. We make an important change to the browserify command. If we list the top-level entry point, browserify will "do the right thing." By that I mean, it will find all the dependencies. It does this by following `require`s. This change becomes helpful when we start to lean on npm more for dependency management.
Since the move to npm, we can use it to manage dependencies. Should make for easier management of future dependencies going forward.
This is all the output of `pulp init`.
We're not doing anything fancy aside from integrating it.
Let's talk about the dependencies:
* bower - We use this dependency to install PS dependencies.
Although the JS community has moved on from it,
the PS community has not.
The problems that affect the JS community,
are not the same problems that affect the PS community.
So, using bower isn't bad for PS.
* pscid - We use this dependency to run a fast file-watcher/compiler.
How it works is kind of complex; suffice to say,
it provides a much smaller feedback loop from the compiler.
* pulp - We use this dependency to make working with the compiler easier.
`pulp` is a wrapper around `purs` that makes it easier to use.
It speaks more at the user-level (`pulp build`, `pulp test`, etc.),
rather than at the tool-level.
The distinction might seem artificial (and is, in some sense).
But, using both in anger shows when one is easier than the other.
For the most part, `pulp` is always easier.
* purescript - We use this dependency to pull down the actual compiler.
Not much else to say about it.
Tracking the compiler as an npm dependency means we can ensure
everyone is using a compatible version.
It doesn't really work in the face of SemVer, but it's close enough.
* purescript-psa - We use this dependency for better errors and warnings.
`psa` is a frontend to `purs` that makes working with errors
and warnings easier than using `purs` directly.
We make PS effectively the entry-point to the program. It takes the `htmlFunction`s and invokes them. The rest of the program should work the same. There is a bit of glue code with this approach. Due to how FFI files work and require paths, we take the PS output and the JS sources, and massage the interfaces together. As we need more JS modules in PS, this glue module should be the place to add them. When we take-over more functionality in PS, this glue module shouldn't have to change.
We arbitrarily choose to take the last three calls and move them to PS. We could've started from the start and worked down. Either way would ensure the same ordering. There's nothing really special about what's happening here. We're calling more JS code and letting it work how it works. The PS is written to resemble the JS to help know show similarities. It's not a requirement to stay this way. In fact, it should most likely change once it's all converted.
Following the pattern setup. Again, it's written to look like the JS to ease the transition.
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What it does
Sets up the PS conversion. The behavior ought to be the same as before once everything is built. This is a top-down approach where PS is effectively the entry-point and it calls out to JS to do stuff.
I threw together a Makefile so it was a bit clearer what all has to happen. Assuming you have make, you ought to be able to say
makeormake index.jsand have everything work. I don't know if it'll actually work, since I assume you're on Windows and cross-platform stuff is hard.In any case, it's probably easiest to look at this commit by commit rather than all in one go. I tried to explain stuff in the commit messages as I went along.
Lemme know if you have any questions or if something should be changed!