feat: add dedupe flag

[KATT]

add dedupe flag that will make sure that complex objects only appear once in the output

[KATT]

It'd be nice with some symbol here (and for circular references fwiw) to show in the JSON that we have replaced it

[Skn0tt]

Agree. I wonder if there's some other implementation that we can draw inspiration from 🤔

Apparently Node.js prints [Circular *1]:

Same with Deno. This might even be a v8 thing.

What if we did [Circular] and [Pruned]?

[Skn0tt]

Implementation looks solid, i'd like to pause a moment to think about the name + location of that flag.

[Skn0tt]

Agree. I wonder if there's some other implementation that we can draw inspiration from 🤔

Apparently Node.js prints [Circular *1]:

Same with Deno. This might even be a v8 thing.

What if we did [Circular] and [Pruned]?

[Skn0tt]

My gut instinct was to put this as an optional parameter to serialize, and call it something like pruneReferentialEqualities, in reference to meta.referentialEqualities. I'd also be fine with dedupeReferentialEqualities. It's a lot longer of a name, but more descriptive I guess? But also harder to parse, so i'm torn between the two. Any strong feelings from your end on this?

[KATT]

Adding an optional argument to serialize could be seen as a breaking change in cases like items.map(superjson.serialize.bind(superjson) 🙃

[Skn0tt]

I see where you're coming from, but I don't necessarily agree with that strict of a definition of "breaking change" 😅

[KATT]

You decide everything and me / @juliusmarminge will just follow suit. :)

Feel free to just push to my PR or make another stab at it, I gotta go for today now!

[KATT]

FWIW, changing the circular to anything else but null could be seen as a breaking change - so maybe it's better to have both as null for now

[Skn0tt]

Published as part of https://github.com/blitz-js/superjson/releases/tag/v1.13.0

[juliusmarminge]

Published as part of https://github.com/blitz-js/superjson/releases/tag/v1.13.0

Awesome. Unfortunately, for some reason I get an error when running the compiled version yelling that SuperJSON isn't a constructor 🤔

[Skn0tt]

Can reproduce locally, let's see what's causing it 🤔

[Skn0tt]

It looks like it's related to how TypeScript emits the export default class. Seems like that bug has existed before this PR, but nobody tried doing new SuperJSON until now!

[juliusmarminge]

It looks like it's related to how TypeScript emits the export default class

Bundling javascript....

Seems like that bug has existed before this PR, but nobody tried doing new SuperJSON until now!

Seems reasonable. Nothing in this PR should cause difference in behavior in that regard

[Skn0tt]

As a workaround, could you try const SuperJSON = require(".").default? That fixed it for me locally.

[juliusmarminge]

As a workaround, could you try const SuperJSON = require(".").default? That fixed it for me locally.

How do you mean? The relative require('.') won't work outside of the local repo. I tried this without success though:

import type SuperJSON from 'superjson'

// eslint-disable-next-line @typescript-eslint/no-var-requires, unicorn/prefer-module
export const superjson: SuperJSON = require('superjson').default({
	dedupe: true,
})

[Skn0tt]

Oops, meant to replace the . with superjson. But you guessed right, that's what I was referring to - doesn't seem to work, though. I'll see what I can do to fix the import ...

[juliusmarminge]

Oops, meant to replace the . with superjson. But you guessed right, that's what I was referring to - doesn't seem to work, though. I'll see what I can do to fix the import ...

Made a temporary workaround that works if you use a named import instead of the default one in #250 🤷🏼‍♂️