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

Question

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

Closed this issue 2 years ago · 14 comments

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

Answer 1 · 2022-08-18T13:08:00.000Z

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

Answer 2 · 2022-08-18T15:32:56.000Z

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?

Answer 3 · 2022-08-21T19:21:06.000Z

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.

Answer 4 · 2022-08-22T11:13:28.000Z

I'll do it now 🙂

Answer 5 · 2022-08-22T11:23:01.000Z

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?

Answer 6 · 2022-08-22T11:24:12.000Z

Clean and simple, I like it

Answer 7 · 2022-08-22T12:07:37.000Z

Yes, please no Control.

Answer 8 · 2022-08-22T20:41:34.000Z

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?

Answer 9 · 2022-08-22T20:50:04.000Z

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. 😄

Answer 10 · 2022-08-22T21:00:48.000Z

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

Answer 11 · 2022-08-22T21:06:52.000Z

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

Answer 12 · 2022-08-22T21:34:07.000Z

😄 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.

Answer 13 · 2022-08-23T20:35:13.000Z

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.

Answer 14 · 2022-11-08T22:09:39.000Z

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