Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Snyk] Upgrade reselect from 4.0.0 to 4.1.8 #183

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

[Snyk] Upgrade reselect from 4.0.0 to 4.1.8 #183

wants to merge 1 commit into from

Conversation

rc042
Copy link
Owner

@rc042 rc042 commented Nov 23, 2023

This PR was automatically created by Snyk using the credentials of a real user.


Snyk has created this PR to upgrade reselect from 4.0.0 to 4.1.8.

ℹ️ Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

  • The recommended version is 15 versions ahead of your current version.
  • The recommended version was released 7 months ago, on 2023-04-16.
Release notes
Package name: reselect
  • 4.1.8 - 2023-04-16

    This release updates our build tooling, tweaks the MergeParameters type to better handle spread values, and fixes an erroneous .clearCache() method included on the resultFunc.

    What's Changed

    • fix types on resultFunc (#591) by @ bdwain in #592
    • Port 5.0 build tooling changes from main by @ markerikson in #606
    • Infer correct state when input selectors are a mix of explicit and rest syntax in createSelector by @ PeterBul in #602

    Full Changelog: v4.1.7...v4.1.8

  • 4.1.7 - 2022-11-04

    This release updates the TS types to work correctly with TS 4.9, which made a change that broke the existing MergeParameters type implementation. Happily, the TS team provided a better (and simpler!) MergeParameters implementation. Since that only works with TS 4.7+, we've reworked the internals to handle providing the old implementation to TS 4.2..4.6, and the new implementation to TS 4.7 and greater.

    As a user, there should be no visible change - just update to 4.1.7.

    What's Changed

    Full Changelog: v4.1.6...v4.1.7

  • 4.1.6 - 2022-06-07

    This release updates the TS types to better handle cases with default parameters, or any/unknown types.

    What's Changed

    Full Changelog: v4.1.5...v4.1.6

  • 4.1.5 - 2021-11-24

    This release updates the TS types to correctly infer selector parameters when input selectors have undefined or null as a parameter type or have optional parameters, and exports the CreateSelectorFunction type to fix uses of createStructuredSelector.

    (The types fixes feel like playing whack-a-mole, but they keep getting better!

    What's Changed

    Full Changelog: v4.1.4...v4.1.5

  • 4.1.4 - 2021-11-17

    This release has (you guessed it) more fixes to the TS types: a change to parameter merging that fixes breakage with selectors and RTK Query's API state, a simplification of the OutputSelectorFields type to improve selector variable readability, another update to parameter merging to flag nested never fields as compile errors, and a fix to createStructuredSelector parameters to resolve a lib compilation problem.

    Changelog

    More TS Fixes

    The parameter merging fixes in 4.1.3 tried to "unwrap/expand" the parameter types to make them more readable, such as showing intersected objects as {a, b, c} instead of {a} & {b} & {c}. This was done with a recursive expansion type. That turned out to break with the complex state types used by RTK Query. We've updated the type expansion to only be a single level instead, which fixes the compilation issue.

    The OutputSelectorFields type previously took two generics: the Combiner function, and a Result type. This led to extra values being shown in hover previews for selectors. By inferring Result = ReturnType<Combiner>, we were able to drop the second generic and cut down on the amount of types shown in previews.

    A user noted that intersected objects with top-level incompatible fields (like {a: string} & {a: number}) resulted in empty objects, but no compile error. We've updated the parameter merging to flag those as never and catch the problem at compile time. Deeper nested incompatible fields should already be caught by TS.

    The previous fix to createStructuredSelector missed a step in the spreading process, which has now been fixed.

    What's Changed

    Full Changelog: v4.1.3...v4.1.4

  • 4.1.3 - 2021-11-16

    This release rewrites the TS type inference of input selector parameters for correctness, fixes inference of createStructuredSelector inputs, and fixes an issue with the OutputSelectorFields type not being exported.

    Changelog

    Input Selector Parameter Inference Improvements

    Reselect's types have always been extremely tricky, because it involves passing multiple input selectors with potentially heterogeneous, and then nested function composition of multiple selectors. Additionally, the input selectors can be passed as individual arguments or a single array of input selectors.

    The 4.0.0 typedefs dealt with this by hand-writing dozens of overloads, which was absolutely impossible to maintain.

    In 4.1, we took advantage of TS's improved abilities to infer array/tuple types to consolidate the typedefs.

    One of the issues that happened as a result was that arguments at the same input parameter index were being "unioned" together, rather than "intersectioned". For example, in this complex selector:

    const input1 = (
    _: StateA,
    { testNumber }: { testNumber: number },
    c: number,
    d: string
    ) => testNumber

    const input2 = (
    _: StateA,
    { testString }: { testString: string },
    c: number | string
    ) => testString

    const input3 = (
    _: StateA,
    { testBoolean }: { testBoolean: boolean },
    c: number | string,
    d: string
    ) => testBoolean

    const input4 = (_: StateA, { testString2 }: { testString2: string }) =>
    testString2

    const testSelector = createSelector(
    input1,
    input2,
    input3,
    input4,
    (testNumber, testString, testBoolean) => testNumber + testString
    )

    The second arg should end up as an object like {testNumber: number, testString: string, testBoolean: boolean, testString2: string}. However, it was ending up as four separate one-field objects. Similarly, the combination of number and number | string should be narrowed down to just number as an acceptable value.

    We've rewritten the types to successfully accomplish that (although it took a lot of collective effort and headbanging to actually pull this off!) This should now give much more correct results when determining the final parameters that can be passed to a selector.

    createStructuredSelector Fixes

    Similarly, createStructuredSelector wasn't always inferring its arguments properly. We were able to reuse the parameter inference work here as well.

    OutputSelectorFields Exported

    The public OutputSelector type depended on an internal OutputSelectorFields type, but since OSF wasn't being exported, TS would throw errors when trying to generate declaration files that exported selectors. That is now public as well.

    What's Changed

    • Rewrite function parameter type inference to fix assorted issues by @ markerikson in #549

    Full Changelog: v4.1.2...v4.1.3

  • 4.1.2 - 2021-11-04

    This release updates the TS types to avoid TypeScript recursion limitations and improve backwards compatibility, adds doc comments to most of the TS types and field declarations, and fixes a bug with the behavior of the resultEqualityCheck option in defaultMemoize.

    Changelog

    TypeScript Updates

    We saw cases where composition of selectors past 8-9 levels of nesting would cause TS to fail with a "Type instantiation is excessively deep and possibly infinite" error.

    We've updated the types to allow additional recursion up to about 15 levels of nested selectors. Hopefully this is enough for most usages :)

    The OutputSelector generic arguments had been swapped during the rewrite for 4.1, which made it incompatible with other code that attempted to import and use that type. We've reverted the generic arguments to their previous order to fix compatibility.

    defaultMemoize adds a .clearCache() field to its return value. While the real caching is done by the memoizedResultFunc function, the actual returned selector has also been run through the memoizer and thus also has a .clearCache() field attached, but that wasn't captured in the types. We've updated the types to reflect that.

    We've also added doc comments to almost all of the internal types for clarity, as well as comments to the returned fields on selectors.

    resultEqualityCheck Behavior

    The resultEqualityCheck option wasn't saving the result if there was a cache hit, which is now fixed.

    What's Changed

    • Update defaultMemoize cache even if resultEqualityCheck is a hit by @ tetslee in #535
    • Make OutputSelector backwards compatible w/ < 4.1.0 version by @ eXamadeus in #536
    • Clarify description of createSelector by @ acrollet in #539
    • Clean up OutputSelector typing and fix bug with memoize function types by @ eXamadeus in #537

    New Contributors

    Full Changelog: v4.1.1...v4.1.2

  • 4.1.1 - 2021-10-26
    Read more
  • 4.1.0 - 2021-10-26
    Read more
  • 4.1.0-beta.2 - 2021-10-24
    Read more
  • 4.1.0-beta.1 - 2021-10-21
  • 4.1.0-beta.0 - 2021-10-21
  • 4.1.0-alpha.2 - 2021-10-20
  • 4.1.0-alpha.1 - 2021-10-17
  • 4.1.0-alpha.0 - 2021-10-16
  • 4.0.0 - 2018-09-30
from reselect GitHub release notes
Commit messages
Package name: reselect

Compare

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.

For more information:

🧐 View latest project report

🛠 Adjust upgrade PR settings

🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@rc042 @snyk-bot