purescript-node/purescript-node-child-process

Add Aff improved API

klarkc opened this issue · 7 comments

We need to add a better wrapper around ChildProcess and Node Streams

  • we'll need to move from pulp to spago to be able to use purescript-node-streams-aff
  • add Aff module with improved API

Related purescript-deprecated/purescript-node-streams-aff#8

garyb commented

We'll need to move from pulp to spago to be able to use purescript-node-streams-aff

I'm not sure where that comment came from, discord perhaps? But it's not true strictly speaking, even though the bower registry is "closed", you can still depend on packages by providing a dependency like "purescript-node-streams-aff": "purescript-node/purescript-node-streams-aff#^1.0.0". We've done that in a few places for projects that don't use spago, or have both options. 🙂

I'm not sure where that comment came from, discord perhaps?

Yes, it was from discord, sorry, I added more info.

But it's not true strictly speaking, even though the bower registry is "closed" you can still depend on packages

I did not tried that, 🤣 but the PR is already there, I am implementing it in the branch with spago, anyway I can rebase into the old pulp version as soon I finish it.

I'm updating Node libraries to v18 and also integrating Aff into such libraries. However, child process is complex enough that I'm not sure Aff things should be added here for two reasons.

First, I'm unsure how Aff would help. There's a number of workflows one might use ChildProcess for (unlike pretty straight forward ones with Stream).

Second, I've written node-execa which handles most of the higher-level stuff people would want.

First, I'm unsure how Aff would help. There's a number of workflows one might use ChildProcess for (unlike pretty straight forward ones with Stream).

@klarkc @garyb Thoughts on what thing Aff would help with?

@JordanMartinez from what I remember from the PR trying to tackle that, it is feasable to have a simple Aff API that does not handle all different edge cases / possible scenarios. Anything more complex will require new API changes - which might not strict follow node API, so I am with you, if execa handle the end-user scenarios I can't see why we should do it again here, given this is a bindings library.

Ok. Then I will close this issue.