xgboost-node VS license-checker

This chips away at one of the showstoppers for Deno for me, which is good.

But while "the vast majority" of npm packages don't require a gyp build step for native addons, some of those modules are pretty important, and I see no indication in the announcement that they're also going to be implementing the Node C API or the gyp build process.

Right now I'm working with a machine learning project, and XGBoost [0] is a direct Node.js extension [1] through the binary interface.

So this does bring things a step closer to being generally usable, but there are still significant roadblocks.

A WebAssembly build of XGBoost could work with Deno, but aside from some guy's unsupported side project/proof-of-concept for use in a browser, I'm not seeing an XGBoost WebAssembly build. And generally when deploying something like a machine learning model I'd rather use well-supported tools than to need to dive into the rabbit hole of maintaining my own.

And yes, XGBoost will likely eventually have that kind of support for Deno, but then the next bleeding-edge project will come along and only support Node.

Even assuming Deno eventually hits a tipping point in popularity where everyone wants to release Node _and_ Deno support in their bleeding-edge projects, there are still things that I miss from package.json that don't seem to exist in the Deno ecosystem.

Things like the "scripts" block: A nice centralized place to find all of the things that need to be done to a project, plus auto-run script entries that can trigger when a project is installed. And inheritable, overridable dependency maps (see the yarn "resolutions" block).

I'd love to jump into Deno, but I think there has been far too much "baby thrown out with the bathwater" to its design. It's the classic development problem of looking at a system and seeing a ton of complexity, but not really understanding that all of that complexity was there for a reason. Maybe when it re-evolves 80% of Node's and npm's features I'll be convinced to make the jump. I'm a huge TypeScript fan after all. But it still strikes me as a violation of "As simple as possible, but no simpler."

[0] XGBoost is a _very_ promising approach to machine learning, training models much faster and with much more accuracy than traditional approaches.

[1] https://github.com/nuanio/xgboost-node

I thought that was a fairly weird question. A couple of our APIs run on Ubuntu, which contains GNU software. He has access to our source code, and I had also previously sent him the output of license checker so he really should have been able to answer this himself.

NPM License Checker

I don't care whether it's all in one file or in a dozen files, but I want all of that information to be available programmatically in a text file (unlike in a readme or on Github) in a standardized location in a project.

In that respect, package.json is a strict win. Your lack of willingness to use `git blame` to see why you added a line, or lack of reasonable git comments, is not to be blamed on the file.

Complexity is unavoidable. How could you write a tool like license-checker [1] for a Go-based project without having license information in a standardized location? Without the scripts section, how can you create a tool like husky [2] that automatically installs git hooks for a project? Every single part of package.json is there for a good reason; at best you could argue that putting some of it in other files would be aesthetically superior, but that's just bikeshedding.

Complexity isn't de facto bad. Some complexity is required if you want a certain level of functionality to become available. Deno (and Go) are slowly accumulating that "cruft" as people realize that those functions are actually useful or even critical to a mature ecosystem.

[1] https://www.npmjs.com/package/license-checker

[2] https://www.npmjs.com/package/husky

Yes, all npm packages are supposed to have a valid SPDX license identifier, and there is an easy way to recursively check these values

For JavaScript I always used davglass/license-checker as a starting point but it's not being maintained anymore. Then I did similar things for the backend code, put everything together and sent it to the legal and security teams. At some point I thought "There must be a better way!". So, I started building sbomx about one and a half years ago. It's working fine enough to show it to the world and gather some feedback.

Check this package https://www.npmjs.com/package/license-checker

Good doctors and drivers make mistakes, too, and they still face liability for those mistakes.

I think that if your company is large enough, you should have employees, or pay someone, to mirror your dependencies and automate license checks. There are projects that do the latter already[1][2]. You can loop your lawyers in if licenses change to ensure you don't violate them. If (A)GPL code still ships in proprietary products, that's a process problem that the company needs to solve.

[1] https://github.com/dhatim/python-license-check

[2] https://github.com/davglass/license-checker

license-checker - Check licenses of your app's dependencies.

If you don't know what licenses you're currently using, I suggest the license-checker NPM tool.

Also, your IT dept is not entirely without concern here, you should be ensuring that you're not violating any open source licenses in your project, and be using something like https://www.npmjs.com/package/license-checker or an equivalent license checking service in your project language to ensure that everything is kosher