Re-export setGlobalDevModeChecks from reselect

[nodwyer4]

Hi, we'd love the ability to directly import setGlobalDevModeChecks from @reduxjs/toolkit rather than importing the values from reselect

We are importing it currently using this so that we can run our test files without the stability checks for performance reasons. We have these turned back on for our tests in CI

const { setGlobalDevModeChecks } = require(
    require.resolve("reselect", {
        paths: [require.resolve("@reduxjs/toolkit")],
    }),
);

Your current exports for re-select

export type { Selector, OutputSelector } from 'reselect'

Happy to raise a pr to change to this, as long as you are happy with the change

export type { Selector, OutputSelector, setGlobalDevModeChecks } from 'reselect'

[markerikson]

I don't think this is a thing I want us to explicitly re-export atm. The request is reasonable, but we've tried to avoid fully re-exporting everything from Reselect and Immer. Another example of this is createStructuredSelector. Yes it exists, and yes there's times you might want / need to use it, but we don't feel it's used often enough to justify explicitly making RTK depend on it. I feel like this falls into the same category. If you specifically need to change that setting, your current approach is the right way to do it - import it yourself directly from reselect.

[ramblingenzyme]

Hi @markerikson,

I work with @nodwyer4 and while this worked while we were using Jest & CJS, as far as I can tell, there's no way to do this in ESM.

If I'm missing something, and there is a way to make sure we're importing a specific version of reselect from the tree, then while annoying, I can understand why you don't want to re-export the entire API surface of Reselect.

For context, we've got v4 of reselect coming in from dependencies and v4 is being hoisted instead of v5, so import { setGlobalDevModeChecks } from "reselect" does not work. It would also never work if we used pnpm or yarn in pnpm mode because reselect wouldn't be at the top level of node_modules, as we don't directly depend on it.

[markerikson]

@ramblingenzyme : I don't understand how module formats apply here. Can you clarify that? Also, why do you have multiple versions of Reselect in the app? RTK specifies which major version of Reselect it depends on.

Beyond that, if you do specifically need to import something from Reselect, the best answer is to directly add it to your actual "dependencies", using the same version that RTK specifies.

[ramblingenzyme]

@markerikson as far as I know there is no ESM equivalent of require.resolve("reselect", { paths: require.resolve("@reduxjs/toolkit") }), so there's no real way to use import to resolve a dependency from the perspective of another dependency.

We have older versions of @reduxjs/toolkit being brought as a transient dependency, which brings in an older version of reselect. This could also happen if to anyone if they had dependencies which directly used older versions of reselect.

Unless there's something I'm missing, and there's a really good way to do this, I would really like this to be exported from the toolkit, particularly because it's configuration of reselect, which only applies to the imported version of reselect, not every version in your dependency tree.

So when adding reselect as a direct dependency, it's possible that the resolved version of reselect from the top level version range could be different from the one from Redux toolkit over time, and the config would stop applying just through lack of attention so it's not a proper and robust fix.

[markerikson]

@ramblingenzyme maybe I'm misreading this, but it sounds like the real issue is you have multiple issues of RTK and Reselect in your dependency tree. What's the reason your app has that happening?

[ramblingenzyme]

@markerikson to be very honest, I don't agree that having multiple major versions of libraries, or not enforcing dependency deduplication can be considered an issue by a maintainer of a public library, as you don't have control over how people consume your package.

As I said, unless there's a good way to replicate the workaround @nodwyer4 originally posted with ES Modules, I think this issue should be reopened for consideration.

[phryneas]

@ramblingenzyme That logic applied thoroughly would mean that every npm package would have to re-export all their dependencies, which would be likely to cause quite a mess.

Usually, things like duplicate package installations need to be tackled on the package manager and bundler level, and there's not a lot package maintainers can do about i.

[markerikson]

@ramblingenzyme My general point here is that our standard recommendation for accessing these additional per-package methods is to explicitly add a dependency on that package so you're not dependent on hoisting. At that point, both RTK and your own deps would normally have matching versions, there would only be one copy of Reselect in your dep tree, and calling the method exported by Reselect would update all Reselect usage including that from RTK.

So, I understand what you're asking for, and why. But I'm also observing that we have a standard alternative recommendation that works for most people, and this appears to be an exceptional case that's specific to complexities in your own app's build setup and dep tree, and we generally try to avoid making API changes unless there's sufficient common usage to justify those changes.