7 ms·

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 diffi

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.

jcpst 4y ago
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/index.js#L47 https://github.com/jcpst/neon-johnston/blob/master/test/inde...
laundermaf 4y ago
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.
- 2fast4you 4y ago
  Why would the test dependencies have access to production secrets? They only get installed while developing
  - hombre_fatal 4y ago
    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.
adobrawy 4y ago
You don't need Jest. You can use buld-in test runner since Node 19.0 (https://nodejs.org/api/test.html 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 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 https://nodejs.org/api/util.html#utilparseargsconfig )
- folkrav 4y ago
  > You don't need Jest. You can use buld-in test runner since Node 19.0 (https://nodejs.org/api/test.html 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 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 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.
  - lightswitch05 4y ago
    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.
simplotek 4y ago
> 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.
bombolo 4y ago
> 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.
- lightswitch05 4y ago
  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.
- bornfreddy 4y ago
  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.
  - bombolo 4y ago
    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.

jcpst 4y ago

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/index.js#L47 https://github.com/jcpst/neon-johnston/blob/master/test/inde...

laundermaf 4y ago

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.

2fast4you 4y ago
Why would the test dependencies have access to production secrets? They only get installed while developing
- hombre_fatal 4y ago
  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.

adobrawy 4y ago

You don't need Jest. You can use buld-in test runner since Node 19.0 (https://nodejs.org/api/test.html 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 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 https://nodejs.org/api/util.html#utilparseargsconfig )

folkrav 4y ago
> You don't need Jest. You can use buld-in test runner since Node 19.0 (https://nodejs.org/api/test.html 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 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 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.
- lightswitch05 4y ago
  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.

simplotek 4y ago

> 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.

bombolo 4y ago

> 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.

lightswitch05 4y ago
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.
bornfreddy 4y ago
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.
- bombolo 4y ago
  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.