Dependency: dequal

[lukeed]

I think it may make sense for swr to replace fast-deep-equal with dequal.

Disclaimer: I'm the author. I don't do this often, but I think it makes sense here.

Dequal is a (slightly) smaller and (significantly) faster alternative. Your usage is very minimal and it's not the ES6 variant, which means you can use the dequal/lite mode too~! That's about ~110B smaller than FDE and is even faster 😅

Because you're not using fast-deep-equal/es6, you can use dequal/lite (no Map, Set, or TypedArray support).
If you choose to support Maps, Sets, and/or TypedArrays in the future, dequal handles them correctly – FDE uses referential equality for Set values and Map keys/values, which doesn't make sense since everything else is value-based equality.

More Info

• dequal vs dequal/lite comparison
• Benchmark Results

[shuding]

Hi @lukeed, great work on the dequal lib! The benchmark looks amazing. For sure we'd love to use a smaller and faster alternative of FDE. Would you mind opening a PR for it (dequal/lite)?

[lukeed]

Sure, thanks!

[o-alexandrov]

I believe due to popularity of lodash, using lodash's isEqual would typically result in lesser bundles than with dequal, as there is a high probability other project's dependencies already use isEqual.

[o-alexandrov]

It's also bad for security, because the more dependencies you have, the higher probability is you missed a security flaw.
npm packages might be deployed with malicious code on an update.

• smaller libraries are harder to track, due to less projects that depend on them and less probability those smaller libraries are scanned

I'm just bringing up a possibility, of course I don't think it's applied to such a famous developer like Luke.

• even though it's possible malicious code might be uploaded unintentionally using credentials of the author

[lukeed]

would you mind, if you open a PR with your library to lodash instead?

Yes I would mind. It's my implementation that I've worked hard on, much like how lodash won't be willing to replace their own implementation from an external developer. Ideologically we also wouldn't agree because my hypothetical PR to them would be mostly deletions, which would be mostly of their own intra-dependencies.

because the more dependencies you have, the higher probability is you missed a security flaw.

I think you're conflating dependency count with code size. Lodash may be a single package install, but it's effectively 60+ modules. And you may think you're importing 1 or 2, but a lot more lodash comes with those.

The rest of your argument I also respectfully disagree with -- lodash, or any other package, is just as prone to issues as anything else -- and may often have more (or be more complicated) because of how much it does and how large/interconnected it is. Popularity isn't a safeguard and/or doesn't equate to correctness.

such a famous developer like Luke.

I'm not famous, but I do care about my packages' quality and integrity. I also have 2FA on all accounts so that there's no risk of impersonation.

end up with 3 different functions that do deep object comparison.

Luckily the ability to alias packages exists at multiple levels - including installation and compile phases. And all these implementations, including dequal, have the same API. That's one of the many benefits of single-purpose, smaller modules.

[o-alexandrov]

And all these implementations, including dequal, have the same API.

I haven't checked whether fast-deep-equal, dequal, and lodash.isEqual do share the same API. It's not always the case though.

I understand your points overall, I just hope, the community would move towards standardization as it's going to promote simplicity for users-developers like me.

• I'm sure in your case, it'd make sense to put your name as the author inside of the changed lodash.isEqual
  • hopefully, lodash members would be reasonable enough to accept that

JavaScript has Standard style (for the way we write code), I just hope more people would be convinced to have standard utilities as well.
Sorry for taking your time and thank you for the discussion :)

[sergiodxa]

The Standard style linter is anything except an standard in the community, and as with that linter there are a lot of popular libs which are not real standards.

If you want to have a deep equal compare function standardised the only way is to add it to the language itself (and even in that case it may not be used by anyone).

[o-alexandrov]

@sergiodxa I know what Standard style guide is as well as other style guides, I've been using it for the whole time of its existence 😅

The Standard style linter is anything except an standard in the community

It's a community standard because it's the most popular style guide. Same applies to lodash.

• but you seem to have a different opinion on what a community standard is, if not the most or one of the most common

[tettoffensive]

@lukeed Really cool library, but this change is making some of my tests fail (using jest).

/.../node_modules/dequal/lite/index.mjs:3
    export function dequal(foo, bar) {

SyntaxError: Unexpected token 'export'

      at Runtime.createScriptFromCode (node_modules/jest-runtime/build/index.js:1728:14)
      at Object.<anonymous> (node_modules/swr/dist/index.js:1:163)

I think it's because of the mjs file because jest ignores node_modules for transformation. I'm not sure if you have any suggestions. I'm trying to figure out how to just transform just the dequal package, but it hasn't worked so far.

[lukeed]

Thanks :) This appears to just be jest resolving, which I know is being worked on now for better ESM support & interop. My guess is that you should just turn on node_modules resolution overall, but perhaps @SimenB can weigh in with a better solution.

[tettoffensive]

Looks like I had to add 2 lines to my jest.config.js:

module.exports = {
  transform: { '\\.m?[jt]sx?$': 'babel-jest' }, // Modify the default by putting an 'm?' at the beginning
  transformIgnorePatterns: ['/node_modules/(?!(dequal)/)'], // Don't ignore dequal
}