Update peer dependencies to include `redux@5` (currently beta) about redux-saga HOT 14 CLOSED

I'll try to prioritize this to get something out of the doors soon-ish

from redux-saga.

@Andarist and I are working through the type issues, hopefully we will be able to figure out some common middle-ground. Will update when we have more time to investigate.

from redux-saga.

@Methuselah96 I fixed this Middleware problem by annotating next as (action: never) => unknown. It's not 100% correct... but I think it should be OK for most practical purposes. The middleware is not something the user is meant to interact with and applyMiddleware accepts it so that's the important part.

from redux-saga.

Redux 5 just dropped. Any updates?

from redux-saga.

So guys, do you plan an update/release soonish here?

from redux-saga.

Could you put out a beta of some kind that ups the dep to "redux": "^5.0.0-beta.0", and test things on your end?

We could do that but it might be an overkill here. It would probably be just fine to release a new version with updated ranges. OTOH, we might not be able to do that right now since redux is the dependency here and not a peer dependency.

Does it make sense for Redux to be a peer dependency rather than a full dependency?

That would make sense but it could be seen as a breaking change. I think that we should:

• inline compose (since that's the only actual runtime "dependency" that we have on redux)
• inline types that we import from redux (structural typing in TS FTW)
• move redux from a dependency to an optional peer dep

I think all of that combined would allow us to avoid all of the breaking change concerns

from redux-saga.

Unfortunately I don't think the redux@4 Middleware type and redux@5 Middleware type are assignable to each other, so that might not work unless we can come up with a type that is assignable to both.

from redux-saga.

Please always try to share a repro case in a runnable form - either by providing a git repository to clone or a codesandbox. OSS maintainers usually can't afford the time to set up the repro, even if exact steps are given.

from redux-saga.

@Methuselah96 I fixed this Middleware problem by annotating next as (action: never) => unknown. It's not 100% correct... but I think it should be OK for most practical purposes. The middleware is not something the user is meant to interact with and applyMiddleware accepts it so that's the important part.

We recently tried updating our store config to use RTK's configureStore instead, but the types of Middleware seem to be incompatible. Concatenating createSagaMiddleware (inside an array ofc) to RTK's getDefaultMiddleware does not work. Is there any alternative to casting createSagaMiddleware to any in this context?

from redux-saga.

Please always try to share a repro case in a runnable form - either by providing a git repository to clone or a codesandbox. OSS maintainers usually can't afford the time to set up the repro, even if exact steps are given.

I'm unable to reproduce this: codesandbox

Seems to work just fine out of the box, so we're probably doing something wrong on our end.

from redux-saga.

Please always try to share a repro case in a runnable form - either by providing a git repository to clone or a codesandbox. OSS maintainers usually can't afford the time to set up the repro, even if exact steps are given.

I'm unable to reproduce this: codesandbox

Seems to work just fine out of the box, so we're probably doing something wrong on our end.

Have you gotten any solution? I'm also getting a typescript error when applying saga as middleware with redux toolkit's configureStore.

const store = configureStore({
   ......
    middleware: getDefaultMiddleware => [
      ...getDefaultMiddleware(),
      sagaMiddleware,
    ],
   ......
});

from redux-saga.

Please always try to share a repro case in a runnable form - either by providing a git repository to clone or a codesandbox. OSS maintainers usually can't afford the time to set up the repro, even if exact steps are given.

I'm unable to reproduce this: codesandbox
Seems to work just fine out of the box, so we're probably doing something wrong on our end.

Have you gotten any solution? I'm also getting a typescript error when applying saga as middleware with redux toolkit's configureStore.

const store = configureStore({
   ......
    middleware: getDefaultMiddleware => [
      ...getDefaultMiddleware(),
      sagaMiddleware,
    ],
   ......
});

We upgraded RTK from version 1.9.7 to ^2.2.0 and that seemed to do the trick. Peer dependencies got upgraded when bumping as well: Redux (5.0.1), Immer (10.0.3), Redux-thunk (3.1.0), and Reselect (5.1.0). Hope that helps.

from redux-saga.

@Yemisrach15 Don't use the spread operator with getDefaultMiddleware(). TS loses type information. Instead, use getDefaultMiddleware().concat(sagaMiddleware).

from redux-saga.

@markerikson @jorgevds Thank you both for the quick reply. Mark's solution worked for me. But I also had to override dependencies as mentioned on the migration guides. I'm not entirely sure why I had to do that. Possible culprit might be redux-injectors since I'm adding it as an enhancer.

from redux-saga.