sanity-io / block-content-to-react

Deprecated in favor of @portabletext/react
https://github.com/portabletext/react-portabletext
MIT License
161 stars 25 forks source link

Upgrade to 1.3.9 causes error #9

Closed ryami333 closed 6 years ago

ryami333 commented 6 years ago

I upgrade a bunch of dependencies in my gatsby application, including block-content-to-react from 1.3.5 to 1.3.9 and now I get this error whenever I try to render a block:

screen shot 2018-05-30 at 10 39 49 pm

I had a dig into source, and this line appears to be the culprit:

var internals = require('@sanity/block-content-to-hyperscript/internals');

mergeSerializers is expect to be a property of that import, but the contents of that file are simply:

module.exports = {
  blocksToNodes: require('./lib/blocksToNodes'),
  getImageUrl: require('./lib/getImageUrl'),
  getSerializers: require('./lib/serializers')
}
rexxars commented 6 years ago

That's odd - 1.3.9 depends on @sanity/block-content-to-hyperscript@^1.3.3, which does export the mergeSerializers function: https://unpkg.com/@sanity/block-content-to-hyperscript@1.3.3/lib/internals.js

Can you take a look at node_modules/@sanity/block-content-to-hyperscript/package.json and see which version it says it is at?

As a workaround, perhaps try removing node_modules and reinstalling all dependencies? I really don't see how it could have upgraded the react module without also pulling down its dependencies in the correct versions.

ryami333 commented 6 years ago

Actually, I poked around inside node_modules, and @sanity/block-content-to-react had the correct version of @sanity/block-content-to-hyperscript nested inside its own local node_modules directory. But it appeared to be resolving the root-level @sanity/block-content-to-hyperscript@1.2.8 which was there as a dependency for @sanity/block-content-to-html@1.3.5. In this particular use-case, I can actually remove @sanity/block-content-to-html as a workaround. But the root issue appears to be an incompatiblity between the html and react packages' dependencies, by way of module resolution.

screen shot 2018-05-30 at 10 56 42 pm
ryami333 commented 6 years ago

And no, a reinstallation of node_modules did not resolve my issue. I am using yarn 1.6.0. Upgrading to latest release of yarn to see if it fixes my issue. Edit: Upgrading yarn does not fix issue.

To be explicit:

node_modules/@sanity/block-content-to-html/package.json -> 1.3.5
node_modules/@sanity/block-content-to-hyperscript/package.json -> 1.2.8
node_modules/@sanity/block-content-to-react/package.json -> 1.3.9
node_modules/@sanity/block-content-to-react/node_modules/@sanity/block-content-to-hyperscript/package.json -> 1.3.3

Also, I can confirm that removing @sanity/block-content-to-html from my application and nuking node_modules fixes the issue.

rexxars commented 6 years ago

Huh, but that doesn't follow the node resolution algorithm... It's supposed to always use the closest module 🤔

ryami333 commented 6 years ago

Yeah, odd eh. I do wonder whether this might be a gatsby bug (or more specifically a webpack bug). Gatsby depends on quite an old version of webpack these days. I wonder if I could recreate this with a minimal codesandbox example with a recent webpack release.

rexxars commented 6 years ago

I've released a new version of block-content-to-html (1.3.6) which depends on @sanity/block-content-to-hyperscript@^1.3.3. That should at least make them use the same version.

ryami333 commented 6 years ago

Cool, thanks for that. I can't replicate this in a sandbox, so I would have to assume that this is indeed an issue that existed in webpack@1.15.0 and it's highly likely it has been addressed since. Thanks for your help :)