Poll for the JS folk!
Suppose there is a JS-based CLI application. It's not that standalone, but rather used in other projects. Like a build system or a linter.
The CLI has some dependencies. Not a lot and not critical, but still. Stuff like colour and CLI manager, perhaps some concurrency library and other utility stuff
What would be your way of delivering it to the end user? I'll go over my personal pros and cons in the replies.
Defining dependencies as dependencies has a benefit of not having to release a new version every time the dependency gets an update. The end user can run `npm up` and the newer versions will be downloaded automatically.
The con of this is the fact that everything gets downloaded. ReadMe, licence headers, in some cases even source code. And, of course, code that never gets executed in your CLI app. Kinda too much download size.
Bundling dependencies + tree shaking can allow you to ship smaller bundles, but the dependencies will get outdated pretty quickly, unless you use dependabot or something to automatically push updates. Smaller size, yet less practical. And if one of your dependencies will have a vulnerability in it, your users won't find out
@NickKaramoff Hu? Just use npm?
AFAIK it's quite poplar to publish CLIs on npm. It installs all them together with the package when you do "npm install".
All others look like workarounds…
@rugk yeahh, but I don't really like making user resolve a bunch of dependencies and bloat their node_modules with unused stuff. Snowpack, for example, ships 7 MB of dependencies 😱
@NickKaramoff well… as long as you install it globally and thus only once on a system, I don't see this as a problem.
Especially if you say that, *any* nodejs/npm project is bloated, because the same applies to non-CLI projects of course. :D
@NickKaramoff the only other way to distribute that would be through a different package manager (like those for Linux distros or maybe chocolately for Windows or so)…
@NickKaramoff Not strictly speaking as a JS dev, but this depends on your specific case.
For simple things like color codes, you can implement them in-tree easily and avoid pulling in sometimes huge packages.
Argument parsing is not that hard either but here it would make sense to use it as a dependency or bundle it to make sure your CLI is not alien to other alike.
I would prefer dependencies over bundling/vendoring in big packages especially just to make sure *your* package is smaller
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.