Hacker News Reader

Comment by ushakov | Hacker News Reader

He’s concerned about adding 1 dependency, while you add thousands to your node_modules without the slightest doubt

What a class act

To be fair, most other projects aren’t as far up-river as curl. Any project they depend on becomes at least as important as curl itself.

Exactly, everything’s a trade-off. And the trade-offs will be different for a very widely used system package like curl compared to, say, a small in-house ERP system or low-traffic website.

For a generally usable implementation, libproxy needs to be able to process proxy auto-config (PAC) files, which are small (or not so small) Javascript programs. These programs are expected the parse the URL and decide which proxy server to use (or a direct connection). It's not declarative at all.

Therefore, libproxy is not a trivial dependency.

True but curl wouldn't need to implement a particularly optimised JavaScript runtime to handle PAC programs, there would be no point in e.g. bundling V8 or ChakraCore with it.

I think quickjs is invented for exact this type of usage. A properly implemented, speed-irrelevant, small runtime for embedded usage.

Most pac files are just a few lines and you don't really need a speedy runtime to run it.

I appreciate when app maintainers set a standard for their dependencies. I wish it wasn't so rare.

Node needs a static dependency checker to prevent using anything that has isodd or similar useless modules in its dependency graph.

Well, yes....

In my general experience, "System Admins" have a security-first mindset along with years of focusing on how to maintain a secure system AND blessing from management to be slower for end-product reliability and security of business assets/data.

Developers, *who can certainly have this mindset and skill set as well*, are typically forced to be more business-oriented with management-dictated objectives/deadlines that more strictly limits their ability to invest the time, so you get "the best I can do in the allotted sprint/deadline time minus the other committed work I need to do".

So inevitably the application will let something through, and it becomes to System Admins' responsibility to protect the company... And that seems to be okay with most businesses.... Developers can move quick fast and dirty, and the operations/admins will try to limit the scope of the blast.

It adds several hours or days of work for a developer to add secret storing/retrieval/rotation compared to just hard-coding a key in the environment, so if they have 2 days to implement a feature, they are not going to spend 2 days implementing extra safeguards unless someone speaks up and pushes back (and the other side relents)

Which is why DevOps, sorry system admins, then have automated tooling for detecting those kind of workarounds, and then we get a sad developer that has to fix a broken pipeline deployment.

In case of places that take security seriously that is.

To be fair, is there any other way around while working with node?

Everything in the ecosystem is a dependency.

> To be fair, is there any other way around while working with node?

breaking robot noises

For the most part, it's also really easy to add node dependencies compared to C/C++. Is it surprising folks take the past of least resistance?

I’ve written a library with zero production dependencies. Of course I have Jest as a development dependency which pulls in all sorts of stuff. It would be difficult to make a zero-dependency library. As for not having production libraries, this was my experience:

1. Using the https module directly was more work than I expected, especially with error handling. This made me really look forward to the new Fetch API coming out.

2. No CLI parser. Its not like parsing args is a LOT of work - but its also something that is already solved and having to write support for that directly was a bummer

3. No logging library. This one was pretty easy. Create a little class with logging levels. Again this is something that is very common that would have been nice to use a package for.

What you describe is exactly why people use dependencies. You just decided to trade your time for the noble act of having “no production dependencies”, while one of the 275 modules installed by Jest (real number) stole your production secrets anyway.

As for point 2, Node 18.1 I think just introduced a native argument parser.

Why would the test dependencies have access to production secrets? They only get installed while developing

They still get run on a developer’s machine most of the time and are at least installed there where they can run arbitrary code on install. And there are juicy secrets beyond just production server secrets sitting on your laptop.

You don't need Jest. You can use buld-in test runner since Node 19.0 (https://nodejs.org/api/test.html)

1/ You do not need to use https / https module directly. You can use Fetch API since Node 17.5 ( https://nodejs.org/api/globals.html#fetch ).

2/ You do not need an external CLI parser. You can use build-in CLI parser since Node v18.3 ( https://nodejs.org/api/util.html#utilparseargsconfig )

> You don't need Jest. You can use buld-in test runner since Node 19.0 (https://nodejs.org/api/test.html)

v19 was released 5 days ago. Barely had time to register this was a thing, let alone migrating our 3500+ unit test+ 300 integration test suite lol

> 1/ You do not need to use https / https module directly. You can use Fetch API since Node 17.5 ( https://nodejs.org/api/globals.html#fetch ). > 2/ You do not need an external CLI parser. You can use build-in CLI parser since Node v18.3 ( https://nodejs.org/api/util.html#utilparseargsconfig )

Lots of production environments tend to sit on latest LTS. v18 _just_ hit LTS, up to last month it was v16. Those weren't really an option for all these projects until then.

Yes, my library absolutely has to support the LTS version of Node, and I run the tests against all supported versions to ensure compatibility. So, one day I can use the nice things people are mentioning, but it will be years from now.

I tried making a tiny test runner that printed nicely to the console. It’s very basic, but I was surprised at how little code it took: https://github.com/jcpst/neon-johnston/blob/master/test/inde...

> I've written a library with zero production dependencies. Of course I have Jest as a development dependency which pulls in all sorts of stuff. It would be difficult to make a zero-dependency library.

That really depends on what your expectations and goals are. You mention Jest but as it's a test dependency then security is not a major concern, and thus it's ok to just vend the source code into your project trees.

> No logging library. This one was pretty easy. Create a little class with logging levels.

Do you print to /dev/stdlog using the correct syslog format or use journald and its format?

Because if it's not one of those, the "levels" are useless.

No, the levels are not useless, far from it. Even if you just print to stdout, prefixing each line with a (maybe colored?) level info is very useful. Also, if later you decide to use xyz format, it is trivial to implement this. Changing all logging calls? Not so much.

Just use a real logging daemon and it will be the colours by itself.

It will also let you query for which level you want.

> Changing all logging calls? Not so much.

Uh? Make a good library using the same interface.

To answer your question, the levels are important for both regular usage and debugging when something goes wrong. I create a number of debug/info/warning/error log messages throughout the tool and allow the desired level of logging to be set as a CLI argument - or even run in silent mode if desired.

It depends on what you're doing.

I wrote https://www.npmjs.com/package/esbuild-copy-static-files only using the Node standard library. It's a small library to make copying static files with esbuild more efficient, it avoids copying files that didn't change. It's useful for watching and copying files in development.

It was funny writing the readme file though where "No 3rd party dependencies" ended up being called out as a feature. I wouldn't have thought to call that out as a primary feature in any other language's ecosystem.

i see "no third party dependencies" often as a feature with C++ libs, and I doubt that's the only place.

In reverse I've seen a banking apps pull in a gigabyte of node dependencies and am thinking there's no possible way they'll ever be able to validate the security of everything.

Well, my application has no tests, badly designed API and no documentation too. So its fiiine

On most of the projects I am involved with, if the modules haven't been cleared for use, the CI/CD pipeline will fail, regardless of working on dev's machine.

If only all projects were as conscious.

this is an inane comparison.

Reply on news.ycombinator.com