Move or fork `purescript-web/purescript-web-promise` to `purescript-contrib/purescript-js-promise`

[sigma-andex]

Promise is available on both, node and web. @i-am-the-slime and I are currently looking into fetch, which is now available on both node and web and transitively it depends on web-promise. So we think it actually deserves to be in purescript-contrib instead.
We think that forking it into purescript-contrib as purescript-js-promise would be the ideal non-breaking change, we can then deprecate web-promise.

Related discussion here: nwolverson/purescript-aff-promise#30

[garyb]

I think just moving it should work, GH does set up redirects when moving things.

But actually, yeah, thinking more about it, that could lead to some confusion if multiple dependencies on it under different names end up in the same project. It'd be more work, but probably would be better to archive this one, fork/push the history of this this into a new repo, and then publish it under the new package namespace

[sigma-andex]

But actually, yeah, thinking more about it, that could lead to some confusion if multiple dependencies on it under different names end up in the same project. It'd be more work, but probably would be better to archive this one, fork/push the history of this this into a new repo, and then publish it under the new package namespace

Yes I agree, it is the safer option to fork it. I can take this over. Do we need more approval for this?

[thomashoneyman]

Yes I agree, it is the safer option to fork it. I can take this over. Do we need more approval for this?

Is it possible to preserve the repo history and push it into a new repository, but not explicitly fork the lib? We have run into some issues when performing upgrades across the contrib organization when a library is a fork. Since web-promise will be archived there's no value in retaining the upstream.

[garyb]

I'll do it now 🙂

[garyb]

https://github.com/purescript-contrib/purescript-js-promise

I guess the question now is what namespace do we use 😄. I'd suggest just Promise, no Control or anything before it. Any thoughts?

[sigma-andex]

Clean and simple, I like it

[i-am-the-slime]

Yes, please no Control.

[JordanMartinez]

I think Js.Promise would be a better idea since this is specific to the JS backend. Don't other languages have a similarly named Promise type that works similarly but may have a different API?

[garyb]

I'm not aware of promises in other languages. Python has Deferred, which is kinda similar, but apart from that other languages have async/parallel/multitasking things as first class language constructs usually.

I looked at some other -js- packages for ideas, we have JSURI, Data.JSDate, and Effect.Timer so it's a complete mess right now. 😄

[JordanMartinez]

😄 Well, maybe we should start standardizing on the Js namespace?

[thomashoneyman]

It's messy because you've got things like Web and Node in there too.

[sigma-andex]

😄 Well, maybe we should start standardizing on the Js namespace?

I don’t think this is a good idea. You would have to start prefixing everything with js, like aff e.g. If anything than maybe have a separate purescript-js orga, but then again I think the only really actively used & maintained backends are js and erlang, and I think the erlang people have their own orgas and package sets anyway, right?
so it doesn’t really seem worth the efforf.

[garyb]

It's messy because you've got things like Web and Node in there too.

I was just looking at the projects that explicitly have -js- in the name and are in contrib for those examples I gave. I think the web/node ones are fine since their namespaces are all prefixed accordingly.

I think I'll go ahead with just Promise. It appears there are indeed quite a few other languages with implementations of a similar thing, Deferred and Future being other common alternative names, but they all work on broadly the same concept. So assuming someone did need want to reuse the same namespace for a different backend, I think it should still basically be possible to use the same foreign declarations to provide the implementation. I guess flattening is something that might not be true across all implementations.

But... I think while this was worth thinking about, it's probably not likely to be an issue. This only really needs to exists for interop - I can't really see anyone writing an otherwise-portable PS library that uses Promise in its implementation, or really using them directly at all when there's the option to convert to Aff.

[garyb]

Next step is to update the libraries that depend on this in favour of purescript-js-promise and then deprecate/archive this repo.