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.
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 (https://docs.pkp.sfu.ca/dev/plugin-guide/en/examples-styles-scripts) 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+.
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?
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.)