Error with importing a library with npm

I am currently developing a plugin for with Coda’s SDK and CLI in a Nodejs environment. I’m facing an issue with importing the “Canvas” library into my code. I don’t need the Canvas library in itself but I need the libraries that have it as dependency. The output of my plugin will be svg data but the libraries I use need canvas to run first.

When I try to execute my code, I receive the following error message:

No loader is configured for ".node" files: node_modules/canvas/build/Release/canvas.node

This is how I am importing:

import * as coda from "@codahq/packs-sdk";
export const pack = coda.newPack();
import * as canvas from 'canvas';

const CANVAS = canvas.createCanvas(1000, 1000, 'svg');

I have already ensured that the necessary dependencies are installed using npm install and have checked the compatibility of the “Canvas” library with my Node.js version. However, I’m still encountering this error.

I would greatly appreciate any guidance or suggestions on how to resolve this issue. Are there any additional configuration steps I might be missing? Could you please provide any insights or instructions on how to properly import the “Canvas” library in a Coda plugin?

Thank you for your help!

I’ll bet @Eric_Koleda knows exactly what this issue is.

Lemme guess - this is Coda’s code sanitation department rejecting any libraries related to the canvas or the DOM?

1 Like

That npm package won’t work on Coda unfortunately, it relies on binaries and it is highly integrated with the OS.


+1 to what @Leandro_Zubrezki said. The .node extension is for binary modules and they won’t work in the Packs Runtime. Sometimes you can use patch-package to prune dependencies that aren’t used in your code path (see here), but if you are generating an SVG it could be that the canvas package is truly required and can’t be removed.

1 Like

Thank you @Bill_French for bringing attention to this.

Thank you @Leandro_Zubrezki and @Eric_Koleda for the clarification. It makes sense.

You gave me good pointers and I’ll dig more in that direction. I’m a bit out of my depth here. Only recently learned node.js and crossed into the server-side of things. Lots to learn.

The library I’m interested in is Paperjs. Been using it for many years so it will be hard for me to abandon it for another one before trying to find some hack first. Old habits die hard as they say and I know it so well now.

Since the library deals mainly with vectors I was hoping that I could at some point in the flow ‘hijack’ all the path and all the bezier curves data that paperjs generates before the canvas is even called into question. Not sure if this thinking even makes sense but I’ll keep researching and thinking. Any materials or additional pointers you could share with me that could help I’ll try to find a solution and share it back with the community. Hopefully there are other Paperjs users out here? :slight_smile:

Thanks for the additional background, I know it’s nice to be able to work with a tool you know well. For such a visual library my guess is that the canvas and DOM elements are rather tightly integrated and it will prove difficult to remove them.

Another option is to spin up a custom API that runs the library in a full Node environment, and have the Pack can make requests to that API to generate the SVG. It requires learning yet another stack (Google Cloud Functions, AWS Lambda, etc) and likely putting up a credit card for the server usage. It’s not ideal, but it allows you to use the library as-is without constraints.


I’d guess the same too. What you’re proposing makes a lot of sense to me, in principle. It might be worth it. Thank you once more for floating that idea!

1 Like