Is there any future for monocle-ts?

[goce-cz]

Hello @gcanti,

First of all, thank you for your enormous contribution to the open-source world and for evangelizing functional programming in TypeScript.

We're currently contemplating adoption of monocle-ts in a mission critical long term project and we see a big potential benefit in it. However we are noticeably concerned about the future of the library as you seem to be stretched pretty thin now. No activity in more than a year and 3 years old experimental API, which should IMO clearly be the default one - kudos for taking the brave step - is a factor that troubles us.

So, I just wanted to ask you: Do you find it realistic for you to keep maintaining the library? Is there a plan of promoting the experimental API to the default one?

Thank you in advance for replying. Any kind of answer will be appreciated.

Best regards, Jiří

[gcanti]

Hello @goce-cz, I am working full-time on Effect-TS, so I don't have much time to devote to monocle-ts and I need to reduce maintenance to a minimum. In short, this means:

• Bug fixes? Yes
• New developments? No

[goce-cz]

Thank you very much for your reply, @gcanti, at least we know where we stand.

Sad to hear that though. :cry:

Any chance we might be getting optics as part of the Effect-TS any time soon? I found a tiny mention in one of the issues, so I remain hopeful.

[gcanti]

A few months ago we worked on an optics library for Effect, it's still in the fp-ts org though (*): https://github.com/fp-ts/optic.

The interesting thing about this new encoding is that there is only one type Optic from which all the other optics can be derived as subtypes, which makes it possible, among other things, to compose optics with a single compose method without the hassle of importing n different modules as in monocle-ts.

(*)

However, the situation is perhaps even worse than that of monocle-ts in terms of reliability, as we don't believe that it is worth maintaining an optics library for Effect as it is a very niche area.

[kalda341]

@gcanti What were the issues around reliability? Do you think it would be better to bet on it over the Monocle experimental API?

I've been considering forking the Monocle experimental API but updating to work with Effect instead of fp-ts. I expect it won't be very hard. Any thoughts on this idea? FWIW Monocle already works pretty well with Effect, it's mostly things like getOption that are annoying to work with.

I'm quite reliant on optics - I have a large deeply nested data structure that I understand is supposed to be bad design but it has served us incredibly well over many years and has enabled huge changes to our product with minimal effort, especially when it comes to data migrations.

[gcanti]

What were the issues around reliability?

@kalda341 I mean that @fp-ts/optic is not currently being maintained, and it is unlikely that it will be maintained in the future unless it is absorbed by the effect org.

I've been considering forking the Monocle experimental API but updating to work with Effect instead of fp-ts. I expect it won't be very hard. Any thoughts on this idea?

Forking the Monocle experimental API should not be difficult. If you have a lot of code based on monocle-ts, this may be the best option for you, especially if you are using traversals, which are not yet fully implemented in @fp-ts/optic.