search

DenisFrezzato / hyper-ts

Type safe middleware architecture for HTTP servers
https://denisfrezzato.github.io/hyper-ts/
MIT License
393 stars 18 forks source link

ReaderMiddleware added #26

Closed mlegenhausen closed 3 years ago

mlegenhausen commented 4 years ago

This PR introduces some breaking changes when trying to import hyper-ts as before but IMHO it is required to integrate new types like the ReaderMiddleware and to align the imports and exports with the rest of the fp-ts ecosystem.

@gcanti I would like to get some feedback from you before I implement all the tests.

mlegenhausen commented 4 years ago

Is already the time to think about hyper-ts-contrib? 😅

How about keeping it compatible with the documented import import * as H from 'hyper-ts' and just add a new module that can be used when needed like import * as HRM from 'hyper-ts/lib/ReaderMiddleware'?

kylegoetz commented 4 years ago

That has worked for me when I've wanted to import { toRequestHandler } from 'hyper-ts/express'. As a user of hyper-ts, doing it this way until a major version bump feels ergonomic.

DenisFrezzato commented 3 years ago

Hey @mlegenhausen, thank you for your contribution. I've started working on adding the ReaderMiddleware module myself and then noticed this PR.

Anyway, I've created another PR with my work, which doesn't introduce any breaking change so it would be more easy for user to upgrade and it can be a patch release. It also follows latest practices in fp-ts (no pipeable, small instances).

I was also planning to upgrade fp-ts and typescript dependencies, so maybe we can introduce the breaking changes later on.

What do you think?

mlegenhausen commented 3 years ago

@DenisFrezzato nice to see new features in hyper-ts! Your PR looks great and of cause offers more modern features than my one year old PR 😅

Which minimum fp-ts and typescript version are you targetting?

DenisFrezzato commented 3 years ago

Which minimum fp-ts and typescript version are you targetting?

At least fp-ts@2.6 (mainly because of TaskEither.chainW, which was re-implemented in this library to not introduce a breaking change). Since it would be a breaking change anyway, I was thinking of targeting fp-ts@2.10 (or even 2.11, as soon as the stable is released), from which I expect should be fairly ease to upgrade to the next3, both for the library and the end user. And latest typescript as well.

What do you think?

mlegenhausen commented 3 years ago

We should keep typescript as low as possible which is mainly the version fp-ts requires cause typescript does not respect semver.

IMHO cause this library is still in 0.x.x I personally would say breaking changes are ok especially when this opens up more flexibility in extending this library.

DenisFrezzato commented 3 years ago

I've just published https://github.com/DenisFrezzato/hyper-ts/releases/tag/0.6.3, I guess this can be closed.

mlegenhausen commented 3 years ago

Thanks!