(Optionally) delete non-nix files

[jonascarpay]

Currently, purenix will only create new files. Maybe it's a good idea to also delete the json files once we're done with them, to leave the directory in as clean a state as possible? AFAICT that's what the JS backend does too.

[cdepillabout]

Maybe it's a good idea to also delete the json files once we're done with them, to leave the directory in as clean a state as possible? AFAICT that's what the JS backend does too.

From reading through the Spago and PureScript code, I believe what happens in the case of JS compilation with purs is that the corefn.json files are just never generated. purs is just called once. It reads the input Main.purs (or whatever) file, and then internally converts it to CoreFn -> CoreImp -> raw JS. It then just writes the raw JS file.

So my understanding is that it doesn't really delete the corefn.json file, it just never needs to write it. We could probably actively delete it though.

There are two other things related to this:

1. Currently purenix looks for all corefn.json files in output/*/, and then transpiles all of them every time it is called.

   In subsequent runs of purenix, I wonder if we'd be able to compare the mtime of output/*/corefn.json and the output output/*/default.nix file, and only perform the transpilation if output/*/corefn.json is newer than output/*/default.nix. This optimization would only be possible if purs also has a similar optimization (so that the output/*/corefn.json files don't get their mtimes updated if the source PureScript file hasn't been changed).

2. Both purs and spago support a bundle command. This causes purs/spago to bundle all the output JS into a single file. This single file can be easily deployed or copied somewhere else.

   It might be nicer for end users if we try to implement some sort of bundling command, rather than just deleting the output corefn.json files.

[jonascarpay]

Ah, that makes sense.

I wonder if we'd be able to compare the mtime...

I don't actually have experience writing this sort of logic, so maybe I'm overestimating the problem, but it seems to me like this could be hard to get right, especially if we want to be able to run on different OS'es?
As long as our conversion runs fast enough, this shouldn't be an issue, right?

Maybe what we could do instead is accept file path arguments, that way we could fit into things like make, although I'm not sure how useful that would be.

Both purs and spago support a bundle command. This causes purs/spago to bundle all the output JS into a single file. This single file can be easily deployed or copied somewhere else.

That seems like a great idea. What does the JS interface to that file look like? How does that interact with FFI files?

[cdepillabout]

I don't actually have experience writing this sort of logic, so maybe I'm overestimating the problem, but it seems to me like this could be hard to get right, especially if we want to be able to run on different OS'es?

I was under the impression that this is basically the logic that make uses, so mtimes are something that can mostly be relied on.

https://www.gnu.org/software/make/manual/make.html#Preparing

The make program uses the makefile data base and the last-modification times of the files to decide which of the files need to be updated.

I'm guessing we could probably do something similar. My guess is that purs does something similar as well.

As long as our conversion runs fast enough, this shouldn't be an issue, right?

I think this is a good point. My guess is that our conversion is way faster than all the type-checking that purs has to do, so it doesn't really matter if we convert all files every time.

I'll create a separate issue about this.

What does the JS interface to [the bundled] file look like? How does that interact with FFI files?

I don't actually know that much about the bundling process. I'll create a separate issue about it. (edit: created at #26)

[cdepillabout]

I created an issue for potentially not running purenix for files where the output default.nix is older newer than corefn.json: #25.

Although, if we deleted the corefn.json file in purenix when outputting default.nix, then we wouldn't be able to use this optimization.