Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

(1) Start by not using packages that have stupid dependencies

Any package that includes a CLI version in the library should have it's dev shamed. Usually that adds 10-20 packages. Those 2 things, a library that provides some functionality, and a CLI command that lets you use the library from the command line, SHOULD NEVER BE MIXED.

The library should be its own package without the bloat of the command line crap

(2) Choose low dependency packages

Example: commander has no dependencies, minimist now has no dependencies. Some other command line parsers used to have 10-20 dependencies.

(3) Stop using packages when you can do it yourself in 1-2 lines of JS

You don't need a package to copy files. `fs.copyFileSync` will copy a file for. `fs.cpSync` will copy a tree, `child_process.spawn` will spawn a process. You don't need some package to do these things. There's plenty of other examples where you don't need a package.



> Any package that includes a CLI version in the library should have it's dev shamed. Usually that adds 10-20 packages.

After your little rant you point out Commander has zero dependencies. So I don’t know what’s up with you.

If the library you’re building has anything with application lifecycle, particularly bootstrapping, then having a CLI with one dependency is quite handy for triage. Most especially for talking someone else through triage when for instance I was out and there was a production issue.

Which is why half the modules I worked on at my last place ended up with a CLI. They are, as a rule, read mostly. Which generally doesn’t require an all caps warning.

Does every module need one of those? No. But if your module is meant as a devDependency, odds are good it might. And if it’s bootstrapping code, then it might as well.

> should have it's dev shamed

Oh I feel embarrassed right now. But not for me.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: