Sharp errors when self-installing libvips

[iEchoic]

My understanding is that sharp uses the global libvips when available, and installs its own when unavailable.

When I install libvips globally, everything works. However, I do not want to rely on global libvips - but when I then do brew uninstall libvips, and re-add sharp, everything builds correctly (and i can see libvips in the node_modules vendor folder) except sharp crashes crashes with the following error every time I try to call it in code:

(sharp:28132): GLib-GObject-WARNING **: 17:30:08.917: cannot register existing type 'VipsObject'

(sharp:28132): GLib-CRITICAL **: 17:30:08.917: g_once_init_leave: assertion 'result != 0' failed

(sharp:28132): GLib-GObject-WARNING **: 17:30:08.917: invalid class cast from 'VipsForeignLoadCsv' to '<invalid>'

Because everything is working fine when I have global libvips, I think this must be a problem with the installation of libvips locally? Please let me know if there's any other info that would help debug this.

What is the output of running npx envinfo --binaries --languages --system --utilities?

System:
    OS: macOS 10.14
    CPU: x64 Intel(R) Xeon(R) W-2191B CPU @ 2.30GHz
    Free Memory: 11.62 GB
    Total Memory: 32.00 GB
    Shell: /usr/local/bin/zsh - 5.5.1
  Binaries:
    Node: 8.9.0
    Yarn: 1.12.3
    npm: 5.5.1
    Watchman: Not Found
  Languages:
    Bash: 3.2.57
    Go: Not Found
    Elixir: Not Found
    PHP: 7.1.19
    Python: 2.7.14
    Ruby: 2.3.7p456

Are you able to provide a standalone code sample, without other dependencies, that demonstrates this problem?
This appears to be an issue with Sharp's installation process failing on specific environment or machine config. Any sharp operation fails, including simply instantiating sharp with a png and then calling .png().

[lovell]

It looks like there are multiple, conflicting versions of libvips installed. Perhaps brew didn't remove one or more versions properly. Try running all of the following commands, in this order, to ensure everything is update-to-date.

brew uninstall vips
brew update
brew upgrade
brew cleanup

Then rm -rf node_modules/sharp and re-install sharp.

[iEchoic]

Thank you for the help. Running those and re-installing Sharp doesn't fix it though, unfortunately. Is there some way to see exactly what version it's trying to use - like somewhere in the code I can put a logline and trace what it's finding globally? Also, if libvips installs locally into sharp's node_modules folder, why doesn't it only use that locally-installed version from that point?

[lovell]

What is the output of running otool -L node_modules/sharp/build/Release/sharp.node?

[iEchoic]

node_modules/sharp/build/Release/sharp.node:
	@rpath/libvips-cpp.dylib (compatibility version 52.0.0, current version 52.5.0)
	@rpath/libvips.dylib (compatibility version 52.0.0, current version 52.5.0)
	@rpath/libglib-2.0.dylib (compatibility version 6001.0.0, current version 6001.0.0)
	@rpath/libgobject-2.0.dylib (compatibility version 6001.0.0, current version 6001.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.5.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)

[lovell]

Thanks, that looks OK to me. Could there be two different versions of sharp in node_modules? What is the output of npm ls sharp?

[iEchoic]

This works as expected:

<ProjectName>@1.0.0 /Users/<username>/GitHub/<projectname>/server/mediaServer
└── [email protected]

---

I think I've discovered the issue, though. We build our server with webpack (so that we can share code and have identical transforms and etc. on the backend w/ the frontend). To prevent this from doing anything funky with node modules, we put all of our node_modules in webpack's externals, so they just get copied directly and not transformed. I don't know why copied files wouldn't work and why they'd need to be aliases, but regardless it seems to not work.

However, it looks like the /sharp/vendor/lib folder is losing its aliases in the process, because files are being copied directly over. On the left we have the working folder, and on the right we have the copied output (note that the files themselves are being copied instead of file aliases):

You can feel free to close this if you'd like as it's related to our build pipeline, though if there's an easy way to fix this or throw an appropriate error it may be worth considering as well. Thanks for the help.

(webpack aside, doing a cp -r on a project will also produce this problem as it will not copy the symlinks over, which may be unexpected behavior)

[lovell]

That's great detective work, thank you for updating this issue with the details.

The prebuilt binary tarballs contain and rely on symlinks. Was there a webpack setting you had to alter to fix its handling of them?

[KillerCodeMonkey]

@iEchoic yeah would be great if you could share some more information. Did you extend the webpack packaging, to copy over the libvips?

[iEchoic]

@lovell @KillerCodeMonkey we have a step after the build now that runs essentially this:

# Sharp relies on symlinks that need to be copied with -PfR flags in order to preserve
# symlinks. Note that cp will *not* preserve symlinks by default without these flags
cp -PfR <project path>/node_modules/sharp <output path>/node_modules/sharp

There's an issue out for the popular copy-webpack-plugin that would allow us to resolve in a cleaner way, should it get implemented.

[tmont]

I ran into this exact same error when upgrading from 0.21.2 -> 0.23.0. The problem for me was that I had a subproject with its own node_modules folder that also had a dependency on sharp (but a different version), and those differing versions interfered with each other.

Once I got all the versions in alignment, the errors went away.