I have been using a fabricjs package (lamatyus:fabric) from atmosphere, which uses an older version of fabric.js.
I have removed this from my project and tried to install fabric with meteor npm install --save fabric this fails with error
node-gyp rebuild
./util/has_lib.sh: line 31: pkg-config: command not found
gyp: Call to './util/has_lib.sh freetype' returned exit status 0 while in binding.gyp. while trying to load binding.gyp
gyp ERR! configure error
gyp ERR! stack Error: `gyp` failed with exit code: 1
gyp ERR! stack at ChildProcess.onCpExit (/Users/annie/.meteor/packages/meteor-tool/.1.6.0.130umtl.ycp7++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/node-gyp/lib/configure.js:336:16)
gyp ERR! stack at emitTwo (events.js:125:13)
gyp ERR! stack at ChildProcess.emit (events.js:213:7)
gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:200:12)
gyp ERR! System Darwin 17.4.0
+ fabric@2.2.2
added 88 packages in 10.952s
on macOS latest.
Any ideas please ? atmosphere was great because it just works, npm seems a bit more voodoo…
I’m showing my ignorance here but why does it need freetype and cairo libs? I can use fabric in a vanilla html/js setup with just an include of the fabric.js script. (like the fabricjs site demos)
I’m no less ignorant - I was looking at your original problem and didn’t (don’t) know any better. The freetype utils will likely only be needed for text rendering. It may be entirely safe to ignore those errors if you don’t need that.
I think this is the problem. I do not want to do server side rendering. I just want to use the fabric library on the client. The atmosphere package works ok but is version 1.7 of fabric. if I use npm to install the 2.2 version this seems to be installing all the server side rendering components too.
This raises is a more general concern I have that using npm to install packages could be adding all sorts of extra code that isn’t needed. Perhaps it’s just me but the biggest folder in my project is the node-modules folder with thousands of files in it.
You could install the meteor package locally and update the npm version it uses. Going from 1.x to 2.x may break it, but it’s worth a try for the 10 minutes to do it.
Edit: make that more than 10 minutes - there’s no github repo linked!
However, the consensus feeling is not to be too concerned about what gets loaded into server code (and it’s normally just a few files from each subfolder). Sure, it may be unnecessary bloat in some cases, but they’re loaded locally, and normally just once (at app startup).
True - but that’s not a meteor package, which is what I was thinking may be worth trying to update.
It may just be that the new versions of fabric.js are built for the browser and Node. In which case, it may be difficult/impossible to uncouple one from the other.
I don’t know the history, so I’m just spitballing.
For Meteor development, since I’m also not using Fabric on the server yet, I just point my main.html to the CDN they give on the Fabric webpage : fabric 2.2.2.min.js or copy this file into Meteor’s client/compatibility folder, and it works very well. Just have to check manually for updates from time to time.
@yiebihan, tried your suggestion in a test app of simply putting it fabric.min.js into client/compatibility folder and that seems to work ok. Other than automatic package updates are there any downsides to using compatibility folder?
I assume that this is creating a global fabric object. The typical fabric usage of capturing a html seems ok
Ineed, @annie, this makes Fabric accessible at a global level. Might be problematic for some libraries with certain dependencies or because of namespaces conflicts, but I have been using Fabric, iScroll and a few others in the compatibility folder for years without any problem - including in commercial mobile apps. One of them has been on both Apple and Google stores for more than a year, it performs really well and we received zero user complaint so far.