Hi Hackers,
We've had some discussion on
another thread in the past couple weeks about pulling in npm to manage our javascript dependencies.
I wanted to pull this discussion back up to the top level and hopefully get some more input.
We recently moved the external front-end dependencies into a /vendor directory to give some much needed clarity between what is pgadmin code and what is vendor code, but we've continued to see some specific pains around the javascript package management.
We discovered that the SlickGrid dependency was out of date and also had a line commented out which prevented an event from firing. That kind of modification to a vendor library can make it very difficult to understand why the code is not behaving as expected.
When we went add a dependency on jasmine, Dave pointed out that we are checking in lots of files that are not necessarily used but typically come packaged with jasmine. My thinking was that it would be easier to upgrade the dependency in the future if it was a simple drop-in and there was no need to customize and pick apart what was in the directory. That said, it does add extra bloat to our codebase when dependencies are checked in wholesale.
Still, it brought back to mind that these issues would be resolved if we were including the libraries using a package management tool.
libraries.txt appears to be a lo-fi manual package management system. It has a record of the licenses that correspond to each library. If there is concern about using a package manager and picking up libraries with incompatible open source licenses, we could consider using a tool like LicenseFinder to run as part of our build and ensure that libraries we are depending on have licenses that make sense for the project.
Dave expressed concerns that this would be adding an extra burden to an already complex development setup process.
Looking around at package managers, I wonder if Yarn might better address some of the concerns about dependency availability and avoiding adding extra steps to a build process. It's provided by Facebook under the BSD license. It looks like they had some of the same concerns about wanting to check in their dependencies but not wanting all the package bloat that would come with checking in a node_modules directory. Thoughts?
Cheers,
Tira