You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: html/creating_my_ideal_react_native_projects_with_typescript_eslint_prettier_and_vscode.html
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -11,7 +11,7 @@
11
11
<linkrel="stylesheet" href="/css/typography.css">
12
12
<linkrel="stylesheet" href="/css/vars.css">
13
13
<linkrel="stylesheet" href="/css/styles.css">
14
-
<linkrel="stylesheet" href="/css/post.css">
14
+
<linkrel="stylesheet" href="/css/post.css">
15
15
</head>
16
16
<body>
17
17
<articleclass="h-entry">
@@ -315,7 +315,7 @@ <h2>tsconfig.json</h2>
315
315
<p>I’ve created a <ahref="https://github.com/mrnickel/ReactNativeTypeScriptConfigDemo">demo project on GitHub</a>. If you have any recommendations on how I can make this better please feel free to submit a PR!</p>
<h1class="p-name">How NPM's Defaults Set You Up for Failure</h1>
20
+
</header>
21
+
22
+
<mainclass="e-content">
23
+
<p>In software development, consistency and stability are critical — especially when managing dependencies. However, NPM’s default behavior when installing packages—using the caret (<code>^</code>) in <code>package.json</code> — creates a fragile environment that often leads to frustrating issues for developers. Idempotent and reproducible dependency management should be the standard experience by default, but NPM’s use of <code>^</code> undermines this goal.</p>
24
+
25
+
<p>Here’s why it’s time to rethink the default use of caret versioning in NPM, and how it sets developers up for future pain, particularly given the complexities of semantic versioning (semver).</p>
26
+
27
+
<h2>Why ^ Versioning Isn’t a Safe Default</h2>
28
+
29
+
<p>The caret (<code>^</code>) prefix in NPM allows minor and patch version updates automatically. For example, if you run:</p>
30
+
31
+
<pre><code>npm install lodash
32
+
</code></pre>
33
+
34
+
<p>NPM adds the following entry to your <code>package.json</code>:</p>
<p>This means that any future installation can upgrade the <code>lodash</code> dependency to anything below <code>5.0.0</code>. While this aims to provide developers with bug fixes and new features without manual intervention, it introduces significant risks: <strong>unexpected changes</strong>, <strong>hidden regressions</strong>, and <strong>version incompatibilities</strong> in complex projects.</p>
40
+
41
+
<h2>1. Semver is Hard—and NPM Makes it Harder</h2>
42
+
43
+
<p>Semantic versioning (semver) is designed to make versioning predictable: major versions introduce breaking changes, minor versions add features, and patches fix bugs. However, not all packages in the JavaScript ecosystem strictly adhere to semver rules. Accidental breaking changes are common, even in minor or patch versions.</p>
44
+
45
+
<p>By defaulting to <code>^</code>, NPM shifts the burden of semver compliance onto developers, who must constantly monitor updates to avoid potential breakages. This behavior creates unpredictable outcomes that often surface in production or CI pipelines. <strong>NPM’s default makes the promise of semver nearly impossible to uphold</strong>, resulting in wasted time troubleshooting issues that stem from unintended updates.</p>
46
+
47
+
<h2>2. A Reproducible Developer Experience Should Be the Default</h2>
48
+
49
+
<p>An idempotent development environment ensures that every code checkout and dependency installation yields the same behavior, regardless of when or where it happens. This level of consistency is essential for stable CI/CD pipelines, reliable production releases, and seamless collaboration across teams.</p>
50
+
51
+
<p>Other ecosystems, such as <ahref="https://go.dev/">Go</a> and <ahref="https://www.nuget.org/">NuGet</a>, use exact versioning to prevent dependency drift. In Go, the <code>go.mod</code> file locks dependencies to specific versions, ensuring builds are reproducible every time. NuGet favors deterministic package management for similar reasons. These approaches prioritize stability by ensuring nothing changes unless a developer explicitly updates a version.</p>
52
+
53
+
<p>In contrast, NPM’s default caret (<code>^</code>) versioning can lead to differing versions on different machines. Reproducing bugs becomes a nightmare when dependencies shift between development, CI, and production environments, making stability difficult to maintain.</p>
54
+
55
+
<h2>3. ^ is a Time Bomb Waiting to Go Off</h2>
56
+
57
+
<p>The flexibility provided by ^ introduces risks that compound over time. Here’s why:</p>
58
+
59
+
<ol>
60
+
<li><strong>Invisible Updates</strong>: Dependencies can be updated silently, resulting in unexpected issues.</li>
61
+
<li><strong>Version Conflicts</strong>: As the dependency tree grows, conflicts arise between direct and transitive dependencies.</li>
62
+
<li><strong>CI Pipeline Failures</strong>: Even if code works locally, a new patch version of a dependency may cause unexpected CI build failures.</li>
63
+
</ol>
64
+
65
+
<p>These issues could be avoided by making exact versioning the default. Developers should have control over when to upgrade dependencies, whether through planned reviews, automated tools like Dependabot, or manually tested patch releases.</p>
66
+
67
+
<h2>4. The Case for <code>--save-exact</code> as the Default</h2>
68
+
69
+
<p>NPM should default to <code>--save-exact</code> behavior, where every dependency is locked to the precise version installed. This would look like:</p>
<p>This ensures that the versions used during development are identical across all environments. Developers can still upgrade dependencies intentionally, but only when they are ready to manage the risks. This approach reduces reactive debugging and ensures a <strong>reproducible</strong> development experience by default.</p>
75
+
76
+
<h2>How to Implement an Idempotent NPM Workflow</h2>
77
+
78
+
<p>If NPM doesn’t change its default behavior, you can take these steps to enforce stability in your projects:</p>
79
+
80
+
<ol>
81
+
<li><strong>Use npm install <code>--save-exact</code></strong>. Set this behavior as the default:
82
+
<code>npm config set save-exact true</code></li>
83
+
<li><strong>Leverage <code>npm ci</code> for CI pipelines</strong>. This ensures only the versions listed in <code>package-lock.json</code> are installed, preventing unexpected updates.</li>
84
+
<li><strong>Use automated tools to manage updates</strong>. Tools like Dependabot can help you control upgrades in a systematic manner.</li>
85
+
</ol>
86
+
87
+
<h2>Conclusion</h2>
88
+
89
+
<p>NPM’s default use of the caret (<code>^</code>) for versioning creates more problems than it solves. In an ideal world, semantic versioning would work flawlessly, but in reality, <strong>semver is hard</strong> — and NPM’s current behavior makes it even harder by encouraging version drift and unpredictable builds. A reproducible, idempotent developer experience should be the default, not the exception.</p>
90
+
91
+
<p>By shifting to <code>--save-exact</code>, NPM would align with practices of more stable ecosystems like Go and NuGet. This change would empower developers to upgrade dependencies on their own terms, reducing surprises and enabling smoother workflows. The minor inconvenience of managing updates manually is a small price to pay for long-term stability and consistency.</p>
92
+
93
+
<p>It’s time for NPM to rethink its defaults and prioritize stability—because predictable software is <strong>better software</strong>.</p>
<p>Made with ♥ by <spanclass="p-given-name">Ryan</span><spanclass="p-family-name">Nickel</span> in <spanclass="p-locality">Toronto</span>, <span>Canada</span></p>
0 commit comments