Roadmap & Next Design

• Separate “core” repository from “integrations” & “contrib” (started)
• Feature parity with ZIO & ZIO Streams in “core” (about 60 % done with all the components already encoded)
• Decent test coverage of “core”
• Enrichment of Array / Option / Either & core modules with effect specific combinators
• Detach HKT dependencies & fp-ts overloadings, keep core independent from any external code
• Introduce @matechs/fp-ts for a full integration layer with fp-ts dedicated instances that fit in the fp-ts typeclasses hierarchy (waiting for v3)
• Introduce “@matechs/legacy” with the old effect system to support a smooth migration path We will keep the old effect as @matechs/effect in order to provide LTS over the prod systems, we will use @effect-ts/* for the future releases.
• Explore a different Functor hierarchy inspired by zio-prelude typeclasses (100% designed, instances still missing for some data types)
• Evaluate if to remove “S” from effect types keeping “Effect” for async ops electing XPure as the principal way to run sync effects

---

28/09: The reason why Effect and its related types have the ability to track sync/async computations is a legacy from the previous version where we didn’t have a specific effect data type for sync computations. With the introduction of XPure, inspired by ZIO-Prelude’s ZPure it is now possible to run sync computations in a stack safe manner with environment management, this dedicated effect type performs better (because its skinned from all the overhead of fibers) and its more specific, XPure per se includes state input and output parameters too. Based on XPure we added a dedicated 3 parameters effect type called XEffect<R, E, A> that is meant to be used in the same way as Effect is but for strictly sync computations. Furthermore the keeping of S is purely a type-level trick and in fact there is no way to assert at runtime if one specific effect is sync or async (and there is also no way to add it because of the intrinsic non introspectability of closures).

15/09: I haven’t updated this issue in a while so I added a recap of every point before. Fundamentally the current state is we decided to target TS 4.1 that enables efficient design of the zio-prelude inspired typeclasses, this makes integration packages to fp-ts no longer necessary (and not possible to some extent given the amount of generics used in zio-prelude data-types).

Overall the plan is to follow the release of TS 4.1 so ideally to have a stable release by November.

Given the target of TS 4.1 and the detachment from fp-ts we will continue support but not expansion on the legacy effect that has been migrated to https://github.com/Matechs-Garage/matechs-effect-legacy targeting compatibility with TS 3.8 to allow companies that have prod code to migrate smoothly, legacy is planned to be deprecated in support by end of 2021.

---

[mikearnaldi]

SF-Scala Talk about zio-prelude: https://youtu.be/OwmHgL9F_9Q

[atrianac]

• To create robust documentation.
• Rename some constructors, such as pureby of or chain by flatMap.
• Explore the ergonomic of the API with the possible introduction in TypeScript of the pipe operator (|>)