@ -65,11 +65,11 @@ Yeah, sort of. I am being pretty "doom and gloom" on purpose to frame this cruci
I should preface this section by clarifying that I'm relatively new to this problem at scale, and there are experts far smarter than myself working to solve and educate on these problems. I'd still like to close this article off with tips that I have for developers who are worried about how to protect themselves further in the future.
I should preface this section by clarifying that I'm relatively new to this problem at scale, and there are experts far smarter than myself working to solve and educate on these problems. I'd still like to close this article off with tips that I have for developers who are worried about how to protect themselves further in the future.
I imagine there are a number of you reading this who are upset that I am appearing to suggest every line of open source code you pull down be audited. We all know that's really not feasible at any scale larger than "demo". This is why there are so many tools, such as [sonarqube](https://www.sonarqube.org/), [snyk](https://snyk.io/), and every project's most diligent contributor [dependabot](https://github.com/features/security) (I am not affiliated with any, just a few I'm familiar with) built with features to track and audit dependencies you've brought in that may contain vulnerabilities. However, these tools don't necessary help if you've accidentally pulled in a bad dependency during development.
I imagine there are a number of you reading this who are upset that I am appearing to suggest every line of open source code you pull down be audited. We all know that's really not feasible at any scale larger than "demo". This is why there are so many tools, such as [sonarqube](https://www.sonarqube.org/), [snyk](https://snyk.io/), and every project's most diligent contributor [dependabot](https://github.com/features/security) (I am not affiliated with any, just a few I'm familiar with) built with features to track and audit dependencies you've brought in that may contain vulnerabilities. However, these tools don't necessarily help if you've accidentally pulled in a bad dependency during development.
When a package is published on npm, save for select circumstances, the version published is there in perpetuity unless npm decides to take it down. Even though `faker@6.6.6` which essentially deletes all of its code is published on npm, it does not remove the history of `faker` releases. Code can only be [unpublished from the registry](https://docs.npmjs.com/unpublishing-packages-from-the-registry) if the package has no dependents, which `faker` had a number of. In this case, and the case of `colors@1.4.44-liberty-2`, npm provides the tools to protect against these releases if you are a direct dependent.
When a package is published on npm, save for select circumstances, the version published is there in perpetuity unless npm decides to take it down. Even though `faker@6.6.6` which essentially deletes all of its code is published on npm, it does not remove the history of `faker` releases. Code can only be [unpublished from the registry](https://docs.npmjs.com/unpublishing-packages-from-the-registry) if the package has no dependents, which `faker` had a number of. In this case, and the case of `colors@1.4.44-liberty-2`, npm provides the tools to protect against these releases if you are a direct dependent.
If you are a newer developer, I recommend understanding [semantic versioning](https://semver.org/) as fully as you can; it is one of the greatest defenses to much of what I've mentioned in this article. The most common practice when using semantic versioning is to use the `^` caret prefix on most of your dependencies because this is what npm does by default when installing a new dependency. It means that any updates to the major version will not be installed, but the latest release of that major version will be used. Similarly, there is the `~` tilde prefix is similar, which will not allow any updates to the minor version. Providing no prefix will pin a dependency at a particular version. If you aren't already, it is highly recommended to use more discretion when deciding which prefix to use on new and existing dependencies you choose to bring in.
If you are a newer developer, I recommend understanding [semantic versioning](https://semver.org/) as fully as you can; it is one of the greatest defenses to much of what I've mentioned in this article. The most common practice when using semantic versioning is to use the `^` caret prefix on most of your dependencies because this is what npm does by default when installing a new dependency. It means that any updates to the major version will not be installed, but the latest release of that major version will be used. Similarly, there is the `~` tilde prefix is similar, which will not allow any updates to the minor version. Providing no prefix will pin a dependency at a particular version. If you aren't already, it is highly recommended to use more discretion when deciding which prefix to use on new and existing dependencies you choose to bring in.
An important caveat here is that even people who were more reserved by only allowing patch releases of `colors`, which should suggest only bringing in bug/vulnerability fixes, still got screwed here by unexpectedly allowing a *very* breaking change. However, this defense is still good against typical, benign cases.
An important caveat here is that even people who were more reserved by only allowing patch releases of `colors`, which should suggest only bringing in bug/vulnerability fixes, still got screwed here by unexpectedly allowing a *very* breaking change. However, this defense is still good against typical benign cases.
The issue with increased discretion is it usually means you have to do more manual work when it's time to update. Working in the Node.js ecosystem is implicitly accepting that everything moves incredibly fast, and it's a danger to your application's continued health to let things fall too far out of date. While far from a perfect solution, one of my favourite ways to combat this is [`npm-check-updates`](https://www.npmjs.com/package/npm-check-updates). It provides an optional interactive environment to select updates to packages that you feel confident are safe. It is a nice convenience in a process that haunts Node.js developers everywhere.
The issue with increased discretion is it usually means you have to do more manual work when it's time to update. Working in the Node.js ecosystem is implicitly accepting that everything moves incredibly fast, and it's a danger to your application's continued health to let things fall too far out of date. While far from a perfect solution, one of my favourite ways to combat this is [`npm-check-updates`](https://www.npmjs.com/package/npm-check-updates). It provides an optional interactive environment to select updates to packages that you feel confident are safe. It is a nice convenience in a process that haunts Node.js developers everywhere.
@ -77,4 +77,4 @@ The sad truth is that there probably is no true way to stop this from affecting
# Conclusion
# Conclusion
I think what happened with `colors` and `faker` is a fascinating case study into how many of us have become complacent with npm's hidden safety concerns. I love open source software, and I believe we can all do out part to ensure we use it safely. I hope this article provided a new perspective to the situation, and whether you agree or disagree feel free to reach out and discuss! I am interested to hear about your experiences.
I think what happened with `colors` and `faker` is a fascinating case study into how many of us have become complacent with npm's hidden safety concerns. I love open source software, and I believe we can all do our part to ensure we use it safely. I hope this article provided a new perspective to the situation, and whether you agree or disagree feel free to reach out and discuss! I am interested to hear about your experiences.
NOTE (Feb 15, 2025): I think this post kinda sucks and I largely disagree with a majority of it now. I've decided to keep it here as posterity, but my modern sensibilities no longer line up with what I wrote here.
NOTE (Feb 15, 2025): I think this post kinda sucks and I largely disagree with a majority of it now. I've decided to keep it here for posterity, but my modern sensibilities no longer line up with what I wrote here.
@ -10,8 +10,9 @@ If you pull up a software dev job posting and check the requirements, there is a
# My Bachelor's Degree
# My Bachelor's Degree
During my undergrad, I hated pretty much everything about school. I knew I loved Computer Science, and I was utterly committed to completing my degree, but I barely made. The system really felt like it was a carefully designed torture chamber made just for me to pay thousands of dollars to suffer in.
During my undergrad, I hated pretty much everything about school. I knew I loved Computer Science, and I was utterly committed to completing my degree, but I barely made. The system really felt like it was a carefully designed torture chamber made just for me to pay thousands of dollars to suffer in.
I loved so many of the concepts and subjects I was learning in Computer Science and Math. However, particularly for Math, the shift in priorities coming to University were a shell shock. The goal of these classes didn't feel like learning anymore; they felt like a game to achieve the best mark. It was a game I sucked at. I don't think there's any words to effectively describe how bad I was at exams. I never properly learned how to cope with my intense distractibility and struggle to focus throughout school, and my memory for concepts I didn't deeply understand was incredibly fragile. My success in any courses, even Computer Science ones, hinged almost entirely on what percentage of the mark was derived from exams. Even worse were the courses that required you to pass the final exam to pass the course (this is the worst of the "torture chamber designed for me"). I failed 2 classes, both through final exams alone: Object-Oriented Programming (which I had done extensively even then, but croaked writing Java on paper), and Probability (which terminated my then-burgeoning interest in Data Science).
I loved so many of the concepts and subjects I was learning in Computer Science and Math. However, particularly for Math, the shift in priorities coming to University were a shell shock. The goal of these classes didn't feel like learning anymore; they felt like a game to achieve the best mark. It was a game I sucked at. I don't think there's any words to effectively describe how bad I was at exams. I never properly learned how to cope with my intense distractibility and struggle to focus throughout school, and my memory for concepts I didn't deeply understand was incredibly fragile. My success in any courses, even Computer Science ones, hinged almost entirely on what percentage of the mark was derived from exams. Even worse were the courses that required you to pass the final exam to pass the course (this is the worst of the "torture chamber designed for me"). I failed 2 classes, both through final exams alone: Object-Oriented Programming (which I had done extensively even then, but choked writing Java on paper), and Probability (which terminated my then-burgeoning interest in Data Science).
I wouldn't think so much about the good old torture chamber now, considering I'm years removed from receiving my degree, but I am constantly upset on reminder of what university could have been for me. My passion has shifted from just Software Development to deep Computer Science. My fiancée loves to poke fun at me for reading basically only CS textbooks, and my spare time is often spent learning about increasingly deep computer science. While I was in school, all I could feel was the stress-rage-hybrid of looming exams, and the intense desire to be free and get what I really wanted; a job as a software developer. I'm so grateful to have achieved that goal, but I still can't help but think about how different my life would have been if I hadn't had to go through something I was so bad at to get there.
I wouldn't think so much about the good old torture chamber now, considering I'm years removed from receiving my degree, but I am constantly upset on reminder of what university could have been for me. My passion has shifted from just Software Development to deep Computer Science. My wife loves to poke fun at me for reading basically only CS textbooks, and my spare time is often spent learning about increasingly deep computer science concepts. While I was in school, all I could feel was the stress-rage-hybrid of looming exams, and the intense desire to be free and get what I really wanted; a job as a software developer. I'm so grateful to have achieved that goal, but I still can't help but think about how different my life would have been if I hadn't had to go through something I was so bad at to get there.
Believe it or not, this article is not just for me to complain how much I hated university and exams (although it was cathartic to write, and I'm leaving it in). Despite how much I hated it, I really can't blame University for being... University. The validity of the post-secondary system isn't really the dialogue I'm going for (at least today). The real point here is that University was simply not for me.
Believe it or not, this article is not just for me to complain how much I hated university and exams (although it was cathartic to write, and I'm leaving it in). Despite how much I hated it, I really can't blame University for being... University. The validity of the post-secondary system isn't really the dialogue I'm going for (at least today). The real point here is that University was simply not for me.
