How to include JavaScript dependencies in OJS plugin project

Description of issue or problem I’m having:
I’m implementing an OJS plugin that as a few JavaScript libraries as dependencies. I’m looking for advice on how to include these into my project. I’d prefer not to include them via a CDN, because I don’t want users to have to rely on a CDN (that might track their activity).

Steps I took leading up to the issue:
Currently I have a little PHP script that downloads the required libraries and saves them in a folder js/lib within my plugin. But that of course means that I have external code (with different licenses) within my project. I have no experience yet with releasing a plugin to the gallery, but that is planned.

What I tried to resolve the issue:
So far I’m trying to think hard if my approach is feasible and I looked around at other plugins but did not find any common practices.
Is it better to have a package.json to load the dependencies? Both with my script and a package.json I could include downloading the dependencies in my release process, so that releases will include all needed files.

Hi @nuest,

Have you seen our plugin guide: It provides some guidance for how plugins should be structured.

PKP Team

Thanks Roger for the pointer - I’m aware of the guide, but didn’t see an example for how to handle multiple JavaScript files. The section in question ( has an example for a local CSS but also remote files.

Is it recommended to load JS dependencies from a CDN when they are registered?

Note that the section of the guide also mentions the enable_cdn option which is AFAIK not available in OJS 3.3+.

Thanks, @nuest.

Perhaps the guidance might be a little outdated and could stand to be updated, as you’re right around the enable_cdn not being an available option so far as I can tell. @NateWr - any thoughts on this?

PKP team

Hi @nuest,

How you manage your dependencies is up to you. OJS does not make any particular assumptions about where your JavaScript comes from. You just tell it which files to load.

If you’re comfortable with package.json and a build process, then that’s probably a great way to do it. Typically, build processes will rename internal dependencies, which will prevent conflicts. (For example, if you load moment.js and another plugin loads a different version of moment.js.)

1 Like

Good point about the conflicts. I could also then make sure to have minified versions, for example.

Thanks @NateWr !

1 Like

Just to note here (possibly for my own benefit in the future): I went with composer and Asset Packagist. Unfortunately, this does create a lot of files, which I manually cleaned up then in a PHP script (pretty hacky but works for now - probably a temp dir and copy would be better, but my PHP skills are bad), see optimetaGeo/composer.json at 48e8c57a5e78199da9ffa895e56e17cb7a20711a · nuest/optimetaGeo · GitHub