Roles declarations to add for v0.14.0 package set

#1

There’s still some work to do before the v0.14.0 release but I’ve audited the purescript, purescript-web, purescript-node and purescript-contrib organizations plus a few more packages to list the types needing roles declarations for a v0.14.0 package set. I’m opening this thread to discuss how to proceed, catch the types I’ve probably missed and coordinate the patches if anyone wants to help.

The following types have a phantom roled argument that should be restricted to nominal:
+ [ ] bodil/purescript-sized-vectors: Data.Vec.Vec
+ [ ] purescript-contrib/purescript-aff-bus: Effect.Aff.Bus.Bus
+ [ ] purescript-contrib/purescript-css: CSS.Size.Angle and CSS.Size.Size
+ [ ] purescript-contrib/purescript-options: Data.Options.Options
+ [ ] purescript-web/purescript-web-xhr: Web.XHR.ResponseType.ResponseType

The following types have phantom roled arguments that should be restricted to representational:
+ [ ] lumihq/purescript-react-basic-classic: React.Basic.Classic.Component
+ [ ] natefaubion/purescript-variant: Data.Functor.VariantF
+ [ ] purescript-contrib/purescript-ace: Ace.Config.ConfigOption
+ [ ] purescript-contrib/purescript-css: CSS.Property.Key
+ [ ] purescript/purescript-enums: Data.Enum.Cardinality

The following types have a representational roled argument that should be restricted to nominal:
+ [ ] fehrenbach/purescript-unordered-collections: Data.HashMap.HashMap
+ [ ] flip111/purescript-ordered-set: Data.Set.Ordered.OSet
+ [ ] hdgarrood/purescript-sequences: Data.FingerTree.Node
+ [ ] purescript/purescript-ordered-collections: Data.Map.Map

I’m not sure about the phantom argument of ST types but some roles of the following foreign data types should be relaxed to representational:
+ [ ] f-f/purescript-react-basic-native: React.Basic.Native.Events.NativeSyntheticEvent
+ [ ] lumihq/purescript-react-basic-classic: React.Basic.Classic.ReactComponentInstance
+ [ ] lumihq/purescript-react-basic: React.Basic.ReactComponent, React.Basic.ReactContext and React.Basic.Ref
+ [ ] natefaubion/purescript-variant: Data.Variant.Internal.VariantFCase and Data.Variant.Variant
+ [ ] nwolverson/purescript-aff-promise: Control.Promise.Promise
+ [ ] purescript-contrib/purescript-aff: Effect.Aff.Aff and Effect.Aff.ParAff
+ [ ] purescript-contrib/purescript-avar: Effect.AVar
+ [ ] purescript-contrib/purescript-nullable: Data.Nullable.Nullable
+ [ ] purescript-contrib/purescript-react: React.ReactClass, React.ReactThis, React.Ref.Ref, React.Ref.RefHandler and React.SyntheticEvent.SyntheticEvent_
+ [ ] purescript-web/purescript-web-promise: Web.Promise.Internal.Promise
+ [ ] purescript/purescript-arrays: Data.Array.STArray
+ [ ] purescript/purescript-effect: Effect.Effect and Effect.Uncurried.EffectFn1 to Effect.Uncurried.EffectFn10
+ [ ] purescript/purescript-exists: Data.Exists.Exists
+ purescript/purescript-foreign-object: Foreign.Object.Object and Foreign.Object.ST.STObject
+ [ ] purescript/purescript-functions: Data.Function.Uncurried.Fn0 to Data.Function.Uncurried.Fn10
+ [ ] purescript/purescript-lazy: Data.Lazy.Lazy
+ [ ] purescript/purescript-record: Record.ST.STRecord
+ [ ] purescript/purescript-refs: Effect.Ref.Ref
+ [ ] purescript/purescript-st: Control.Monad.ST.Ref.STRef and Control.Monad.ST.ST

I’m not familiar with Halogen nor React Basic Hooks but they’ll probably need roles declarations too.

2 Likes
#2

Could we create a separate fork in the package-sets repo and slowly build a separate v0.14.0-compatible package set? In other words, a repo can only be added to that version of the package set once it is v0.14.0-compatible library (all errors and warnings are removed). That might help us manage some of the ecosystem breakage better without disrupting PS v0.13.x users.

3 Likes
#3

By “separate fork in the package-sets repo”, do you mean a v0.14.0 branch on the official repo? Or should we build upon the fix-warnings-ps-master-compatible branch of your fork?

I’ve opened a few pull requests to the repositories with v0.14.0 branches.

Should we open such branch on the repositories lacking one or would it be enough to refer to forks in our v0.14.0 compatible package set?

1 Like
#4

Sorry for not being clearer. Yes, I mean a separate branch in the repo.

Regarding your other question, I’m not sure. I think core contributors would have to comment on that.

1 Like
#5

I can create such a branch so that we can start working on that, but we won’t be able to get CI to run with the 0.14 compiler until that is actually published, unless someone builds the compiler from the latest commit and integrates that into the CI. Is this still useful?

EDIT: I created the prepare-0.14 branch

1 Like
#6

@f-f Thanks!
@kl0tl I believe you’re es-modules branch of the package sets has the most libraries that are currently compatible, correct?

1 Like
#7

For CI (and other purposes), should we create release candidates of the compiler? I like how Julia handles the release process, where it’s easy for package maintainers to check for bugs ahead of the the official release. Generally, you just add the release candidate to your CI matrix.

3 Likes
#8

I don’t feel ready to publish something I’d call a “release candidate” because there are still a couple of quite serious bugs in Coercible which we haven’t fixed yet, but yeah, we can do a pre-release. We’ve done them in the past.

3 Likes
#9

Thank you @f-f!

@JordanMartinez I branched es-modules off your own fix-warnings-ps-master-compatible branch, there’s only a few fixes for deprecated primes in foreign modules exports on it.

The diff is quite messy because of some auto-formatting but most of the pull requests I opened were merged and some new versions were released so here’s the gist of the changes:

  • arrays, bigints, decimals, jquery, node-buffer, node-he, node-postgres, refs and web-html should be upgraded to master
  • assert, signal and st should be upgraded to the no-foreign-primes branch of my forks

I’ll be unavailable for a week or so but I can open a pull request for these (and for the many libraries I added roles declarations to) on the package-sets repository when I come back from my vacation week without computer!

2 Likes
#10

See this PR where I attempt to merge es-modules into @f-f’s prepare-0.14 branch.

1 Like
#11

Actually, I’m remembering now why I stopped working on a ps 0.14-compatible package set. Unless it is announced that the next release is going to come out in a week or two after that announcement, it’s not worth the time to work on and maintain a separate fork that is compatible. Otherwise, some repos will make modifications to them and thereby outdate one’s fork. As I worked on the above PR, I noticed that a few repos to which I had submitted a polykindsUpdate PR haven’t been merged with the repo’s master as changes have been made to that repo.

1 Like