-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can the node-canvas dependency be made a peer dependency? #1252
Comments
What's a peer dependency? I never heard of the concept. I agree that with more and more people using NPM for browser libraries, we have to find a better solution. |
Related: #1171 (comment) |
I think this article may explain it better: https://nodejs.org/en/blog/npm/peer-dependencies/ |
Hmm but this doesn't sound like it would solve the issue. Peer dependencies will have to be installed, no? |
Yes, after giving it a little thought I see that it might not be the best way. Let me try figuring out something which solves this issue. I'll ping back with some results soon. |
We already define it as an optional dependency, but these get installed by default, unless you choose to exclude it:
|
Here's another idea: We could have a pure |
I think there are plugins which might help with this such as Lerna: https://github.com/lerna/lerna |
@kumarharsh thanks for the hint, that looks interesting. I shall investigate this further. |
Planend are the modules paper-jsdom and paper-jsdom-canvas, as shim modules that require and handle the dependencies as peer dependencies. Relates to #1252
I have started implementing this now in 29de03d: Planend are the modules The core |
@lehni any news about this? I see it hasn't been merged into master yet. |
I haven't found time yet to work on this... |
@lehni ok, I understand. |
+1. @lehni I'd also like to lend my hand, if you can tell me what to do. |
@tom10271 has pointed out a way to achieve this now already, here: Unfortunately I can't provide reliable estimates. I take care of @kumarharsh the plan is outlined above, but what I haven't figured out is how to handle versions... Will But maybe, the trick found by @tom10271 is good enough to not have to take care of such separate packages? |
@lehni Thanks for the suggestion. That workaround is the one I am using now to workaround the problem. Regarding the split I think you're right, the version should be locked to |
Bower is for web projects only, the node-canvas module isn't even in its registry : ) |
@lehni yes I know. Sorry, bad choice of words. Btw, #1308 (comment) doesn't seem to work. I'm investigating to check if I made something wrong in my package.json definition. |
@lehni I don't think the format @tom10271 suggests in the linked comment is recognized by npm. Ref: https://docs.npmjs.com/files/package.json#dependencies |
@lehni can you push the changes you've done (as described here) into a new branch, maybe I can take a shot at completing it? |
I have an updated solution. Please check: #1308 (comment) Thanks |
Tested right now! It works like a charm. |
It works. For yarn, you'd need to run |
Yeah we need a proper fix. @kumarharsh I had it working locally, the missing bit is only the automatic publishing of these shim modules with each publishing of paper itself... This needs a gulp task. |
e.g.:
// Just pass through. The rest is handled by the paper.js library itself:
module.exports = require('paper');
{
"name": "paper-jsdom",
"version": "0.10.4",
"description": "The Swiss Army Knife of Vector Graphics Scripting, packaged for headless use in Node.js",
"license": "MIT",
"homepage": "http://paperjs.org",
"repository": {
"type": "git",
"url": "git://github.com/paperjs/paper-jsdom"
},
"bugs": "https://github.com/paperjs/paper.js/issues",
"author": "Jürg Lehni <juerg@scratchdisk.com> (http://scratchdisk.com)",
"main": "index.js",
"files": [
"index.js",
"README.md"
],
"engines": {
"node": ">=4.0.0"
},
"dependencies": {
"paper": "0.10.4",
},
"peerDependencies": {
"jsdom": "^9.4.0",
"source-map-support": "^0.4.0"
},
"browser": {
"jsdom": false,
"jsdom/lib/jsdom/living/generated/utils": false,
"source-map-support": false
},
"keywords": [
"vector",
"graphic",
"graphics",
"2d",
"geometry",
"bezier",
"curve",
"curves",
"path",
"paths",
"canvas",
"svg",
"paper",
"paper.js",
"paperjs"
]
} |
The part I wasn't so sure about was |
IMO, you can put |
Yeah I agree... |
I am on this now, expect |
Alright, it's all published now! https://www.npmjs.com/package/paper Please test and let me know if it works. |
Oh darn, this should really be |
Alright, |
Tested it, and it looks good to me. |
Perfect! 🎉 |
Great to hear! I was thinking that node folks could also do this instead, in the main project: "dependencies": {
"canvas": "^1.3.5",
"jsdom": "^9.4.0",
"paper": "^0.11.2",
"source-map-support": "^0.4.0"
}, And after that, this would work just as well: require('paper'); But the shim packages are still useful for easer dependency management and updating... |
I'm using |
Yes it does make sense. Glad to hear it works for you, too! : ) And updating happens automatically now through a Gulp tasks that keeps the versions in sync and publishes along with the main library, so it's not an additional managing effort. |
While I was at it, I also streamlined the whole publishing process, which is now fully automated through Gulp. This also handles changes to the http://paperjs.org/ website, to which it now automatically pushes the new references, ZIP package and JS asset. And https://github.com/paperjs/paperjs.org now has a Travis CI worker that deploys the site statically to Github Pages at https://github.com/paperjs/paperjs.github.io every time a push happens to it. So releasing a new version unravels a sequence that results in everything being up to date. Pure magic! |
On one of my projects using paperjs, every single
npm install
node tries to install thecanvas
dependency. This fails (because I don't have cairo, etc) and I since I'm going to use this purely in browser, I will never need node-canvas to be installed. But the waynpm install
works, since it doesn't find canvas already in the node_modules folder, it tries to install canvas on each try, thus slowing down every single instance ofnpm install
. I believe moving canvas to apeer dependency
would solve this issue. Also, it will mean that the developer has to explicitly specify that their project depends onnode-canvas
, which I find to be more desirable. What do you think?The text was updated successfully, but these errors were encountered: