Replace constructor.name with a bulletproof solution

Question

Replace constructor.name with a bulletproof solution

Closed this issue 9 years ago · 8 comments

When using minified immutable.js build, serialization fails. It is possible for Maps (for instance) to be serialized as {"__iterable":"de"} as the constructor name is minified.

Answer 1 · 2017-01-25T19:03:06.000Z

Interesting side-effect and corner case... working in a mono-repo via Lerna that has two packages with two instances of Immutable fails the comparison check. PackageA emits a Immutable.Map that PackageB then has to serialize.

This is such a corner case that I wouldn't expect you to even consider this, but this has cause my CI pipeline to fail as a result 😝

Answer 2 · 2017-01-25T19:15:07.000Z

Yeah I noticed it too, but that's kind of your mistake to have multiple instances of immutablejs. Dne 25. 1. 2017 8:03 odp. napsal uživatel "Chris Peddecord" < notifications@github.com>:

…

Interesting side-effect and corner case... working in a mono-repo via Lerna that has two packages with two instances of Immutable fails the truthiness check. PackageA emits a Immutable.Map that PackageB then has to serialize. This is such a corner case that I wouldn't expect you to even consider this, but this has cause my CI pipeline to fail as a result 😝 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD9ivVcQVFEGfB78qOw2qA7mOqpFgS6Wks5rV5xqgaJpZM4Lm6N0> .

Answer 3 · 2017-01-25T19:17:46.000Z

So if I take your comment correctly, using Lerna to manage several linked packages is a mistake? Seems like an issue with Lerna, honestly.

Answer 4 · 2017-01-25T19:50:16.000Z

Don't know what Lerna is, but if it keeps multiple instances of the same package inside a build, it's not great thing.

Answer 5 · 2017-01-25T19:51:56.000Z

Lerna is tooling to help manage mono-repos, you can see the issue I'm having here:

lerna/lerna#176

Answer 6 · 2017-01-25T23:31:38.000Z

I did consider this issue before deciding on this but it seems such marginal that I did not even mention it.

I would suggest keeping only a single installation of immutable.js in a project. If any dependency of yours uses a different installation, would it be possible to dedupe them?

We were using the following command for this:

$ find . -name 'immutable' | grep -v '^\./node_modules/immutable' | grep 'node_modules/immutable$' | xargs rm -rf

Answer 7 · 2017-01-25T23:56:44.000Z

It's a bit of a marginal issue to be sure and likely not worth consideration, to be honest. Lerna's set to be updated soon enough so this shouldn't be an issue for too much longer. My bash-fu isn't the strongest, but I was thinking I could do something like this, thanks for the help!

Answer 8 · 2017-01-27T16:59:24.000Z

another wrinkle due to the change, if we're running locally and using npm link my-package-name-here we run into two different instances of immutable again. While I'm sure this works fine when you're plain npm install'ing your package, local development is hamstrung.