DEV Community: Tertiumnon

package.json, package-lock.json, and Semantic Versioning: Why You Need to Understand This

Tertiumnon — Wed, 05 Aug 2026 11:44:46 +0000

If you've ever run npm install and then spent an hour and a half debugging why everything works locally but fails in production, this article is for you. That was probably a dependency version issue — the exact problem that proper semantic versioning and lock files solve.

Why versioning exists in the first place

Imagine: you wrote an app using React 18.2.0, and it works perfectly. A month later, React 18.3.0 is released. Should you automatically get this update? It depends on what changed. If it's only bug fixes, it's probably safe. If there's a breaking change that breaks half your code — no way.

That's exactly why semantic versioning (semver) exists. It's a standard that says: the version number carries information about what changed in the package.

Semantic versioning: MAJOR.MINOR.PATCH

A version consists of three numbers: MAJOR.MINOR.PATCH. For example, 1.2.3.

MAJOR (first digit) — breaking changes that break compatibility. If you update from 1.x.x to 2.x.x, prepare for some code to stop working.
MINOR (second digit) — new features, but backward-compatible. Updating from 1.2.0 to 1.3.0 should be safe.
PATCH (third digit) — bug fixes. Updating from 1.2.3 to 1.2.4 is just fixes.

The official semver specification states it clearly: increment MAJOR for incompatible API changes, MINOR for backward-compatible new features, and PATCH for backward-compatible bug fixes.

Example of an exception: TypeScript is a counterexample. According to its official stance, TypeScript explicitly does not follow semver and introduces breaking changes in MINOR releases. This means upgrading TypeScript from 5.3.0 to 5.4.0 could break your build — and it's formally correct by version number, but not by semver standards. Lesson: even major versions don't guarantee a package follows semver.

Versioning in package.json: operators and symbols

This is where the fun starts. When you write a version in package.json, you can use different operators. Each tells npm which updates to look for during installation.

Exact version (no symbols)

{
  "@prisma/client": "6.19.3"
}

This means: install exactly version 6.19.3, no higher, no lower. Pros: absolute predictability. Cons: if 6.19.4 comes out with a critical bug fix, you won't get it until you manually update package.json. And if you forget about it... well, you get the idea.

Caret (^) — safe updates within major version

{
  "@prisma/client": "^6.19.3"
}

The caret says: update MINOR and PATCH within the current MAJOR. So 6.19.3 → 6.20.0 → 6.99.9 is okay. But 7.0.0 is not. This is npm's default when you run npm install <package> without flags.

Why this is good: new features (MINOR) should be backward-compatible, so updating is safe. Bug fixes (PATCH) don't need worry at all.

Why this can be problematic: what if a package violates semver? Or what if a transitive dependency of some obscure library got a breaking change in its "minor" version? That's why lock files exist.

Tilde (~) — only patches

{
  "@prisma/client": "~6.19.3"
}

The tilde is more conservative: update only PATCH within the current MINOR. So 6.19.3 → 6.19.4 → 6.19.99 is okay. But 6.20.0 is not.

When this is useful: if you're working with a very unstable library where even minor versions can break things. Downside: you miss new features.

Greater than (>) and less than (<)

{
  "express": ">4.17.0",
  "lodash": "<5.0.0"
}

This literally means what it says: install any version strictly greater than 4.17.0 or strictly less than 5.0.0. With >= and <= it's the same, but you include the boundary value.

When you'd use this: rarely. Usually you combine them: "express": ">=4.17.0 <5.0.0" means "from 4.17.0 to 4.99.99".

Equals (=)

{
  "react": "=18.2.0"
}

This is the same as just "react": "18.2.0". Exact version, nothing else.

Asterisk (*)

{
  "react": "*"
}

Accept any version. Including 0.x.x-alpha-dev-666. You rarely see this in production code because it's basically a lottery.

Combining operators

According to npm documentation, you can combine operators with spaces:

{
  "react": ">=18.0.0 <19.0.0"
}

This means: from 18.0.0 to 18.99.99 inclusive. Practically equivalent to ^18.0.0, but explicit.

package-lock.json: why it's your lifesaver

Here's a scenario without a lock file:

Day 1, Machine A (your laptop): you write ^@prisma/client: 6.19.3 in package.json and run npm install. The latest version at that moment is 6.19.5, so npm installs it.
Day 2, Machine B (your colleague's machine): he clones the repo, sees ^6.19.3, and runs npm install. But 6.20.0 has just been released — so he gets that instead.
Chaos: it works for you, it doesn't for him. Or worse — tests pass locally but fail on CI/CD, where the build happens at yet another point in time.

package-lock.json is a file that npm automatically creates and updates when you run npm install. It records the exact version of every package and every dependency that was installed. When another developer or CI runs npm install, npm reads this file and installs the exact same versions, regardless of what ^ is in package.json.

This is why lock files are critical to commit to git:

# ✓ correct
git add package.json package-lock.json
git commit -m "Add dependency"

# ✗ wrong
echo "package-lock.json" >> .gitignore
git add package.json
git commit -m "Add dependency"

If you don't commit the lock file, every installation becomes a lottery. Imagine you're using ^ everywhere, and two weeks pass between your local update and the production server update. 50 new dependency versions are released. The probability that all of them are compatible and no one violated semver — approaches zero.

According to research, real packages constantly violate semantic versioning: TypeScript introduces breaking changes in minor releases, PostCSS plugins silently change CSS output. This means lock files are not just convenience — they're your first line of defense.

The horror story: when versioning breaks your project

Scenario 1: Forgotten bug fix

You locked ~express: 4.17.0 and forgot to update. Version 4.17.5 comes out with a critical security fix. You don't get it because you explicitly wrote ~, not ^. Three months later, hackers exploit that vulnerability. Not fun.

Scenario 2: Transitive dependencies

You installed some-lib version 1.2.0, which depends on other-lib: ^2.3.0. When you installed it, that was 2.3.5. A week later, other-lib@2.4.0 comes out with a breaking change. Your colleague clones the repo, runs npm install without a lock file — and gets 2.4.0 because the caret allows minor updates. His build breaks, yours works. All because there was no lock file.

Scenario 3: CI/CD roulette

On your machine npm install, on CI machine npm install (or worse — no lock file). Different versions, different results. Code passes local tests but fails on CI. Then you spend two hours wondering why the same thing works differently.

Different lock files for different package managers

If you're switching from npm to yarn, pnpm, or Bun, it's important to know:

npm uses package-lock.json
yarn uses yarn.lock
pnpm uses pnpm-lock.yaml
Bun uses bun.lock

Structurally they differ slightly (pnpm-lock.yaml, for instance, is optimized for pnpm's content-addressable storage, and bun.lock is designed for maximum speed and Node.js ecosystem compatibility), but the essence is the same: they lock exact versions. The key thing:

Never commit lock files from different package managers simultaneously. If you're switching from npm to pnpm or Bun, delete the old package-lock.json:

rm package-lock.json
pnpm install
git add pnpm-lock.yaml package.json
git commit -m "Migrate to pnpm"

Or when switching to Bun:

rm package-lock.json yarn.lock pnpm-lock.yaml
bun install
git add bun.lock package.json
git commit -m "Migrate to bun"

If you leave multiple files, they'll conflict and confuse your teammates.

Common developer mistakes

Mistake 1: Adding lock file to .gitignore

# ✗ mistake
echo "package-lock.json" >> .gitignore

This turns versioning into a casino. Commit lock files always.

Mistake 2: Manually editing lock files

Lock files are automatic. Don't touch them by hand. If you need to update a dependency, use:

npm update package-name  # update within range
npm install package-name@desired-version  # install specific version

Mistake 3: Exact versions everywhere

{
  "react": "18.2.0",
  "express": "4.17.1",
  "lodash": "4.17.21"
}

This is conservative but tedious. You miss bug fixes. Use ^ by default — that's what semver is designed for.

Mistake 4: Wrong lock file handling during branch merges

If you have a merge conflict in package-lock.json, don't try to resolve it manually:

# ✗ wrong: manually editing a lock file
git add package-lock.json  # after manual editing

# ✓ correct
git checkout --ours package-lock.json  # or --theirs
npm install  # npm will automatically update the lock file
git add package-lock.json package.json

npm will sort out the conflict on the next install.

Mistake 5: Using npm install instead of npm ci in CI/CD

# ✗ may update the lock file
npm install

# ✓ guarantees exact versions
npm ci  # clean install

npm ci is specifically for CI environments — it installs exactly what's in the lock file without updating it.

How to properly work with versioning

Use ^ by default:

   {
     "react": "^18.2.0",
     "express": "^4.17.0"
   }

This lets you get bug fixes and new features automatically but protects from breaking changes.

Commit the lock file:

   git add package.json package-lock.json

Update dependencies through npm, not manually:

   npm update            # update within ranges
   npm outdated          # see what updates are available

Use npm ci instead of npm install in production:

   npm ci

If you need absolute stability, use ~ or exact versions — but only for critical dependencies:

   {
     "critical-lib": "~1.2.3",
     "regular-lib": "^1.2.3"
   }

Regularly update dependencies, but do it intentionally:

   npm audit              # check for vulnerabilities
   npm audit fix          # auto-fix
   npm outdated           # see available updates

Final checklist

✓ I understand that MAJOR.MINOR.PATCH means breaking/new/fix
✓ I use ^ for flexibility, ~ for conservatism
✓ I commit package-lock.json to git
✓ I use npm ci in CI/CD, not npm install
✓ I never manually edit lock files
✓ I don't commit lock files from different package managers at the same time

That's all you need to avoid those soul-crushing hours of debugging "works on my machine but not in production."

Sources

SolidJS vs React (2026)

Tertiumnon — Mon, 27 Jul 2026 09:16:45 +0000

React remains the de facto frontend standard, but over the past couple of years SolidJS has built a solid reputation as "the framework that got reactivity right." Solid has no virtual DOM, a component runs exactly once, and updates land with surgical precision. That sounds like marketing copy, but it's a direct consequence of the architecture. Let's dig into where SolidJS is genuinely ahead of React on a technical level, what the current 2025-2026 benchmarks and surveys actually say, and — without sugarcoating it — where React still wins by a wide margin.

Reactivity: signals vs the virtual DOM

The core architectural difference sits at the heart of rendering. In React, a component is a function that re-executes in full whenever state changes; the result is diffed against the previous tree via the virtual DOM, and only then are targeted patches applied to the real DOM. It's a convenient model, but it charges a computational tax on every update, even when a single text field deep inside a nested tree is all that changed.

SolidJS works fundamentally differently: JSX compiles down to plain DOM node creation calls, and state lives in signals (createSignal) that the component reads once, during the first render. After that, the component function's body never runs again — instead, fine-grained reactive subscriptions are wired up directly: a specific DOM node subscribes straight to a specific signal and updates without any tree comparison whatsoever. Developers call this fine-grained reactivity, as opposed to React's "coarse-grained" component re-rendering. One commenter on the Solid 2.0 beta puts it bluntly: Solid has always had the best reactivity model among JS frameworks — true fine-grained updates without a virtual DOM. That's a bold claim, but it's backed by a concrete architecture that skips the diffing pass entirely, not just the author's personal enthusiasm.

Signals have long stopped being one framework's party trick — even competitors have adopted the idea. Angular officially acknowledged that its own signal-based reactivity model (signal(), computed(), effect()) was partly inspired by SolidJS: in the Angular Signals RFC, the Angular team directly credits Solid's creator, Ryan Carniato, for the insight and consultation he provided during the design process. When a framework the size of Angular — one that's been tied to Zone.js and its own change-detection model for a decade — pivots toward Solid's ideas, that says more than any marketing ever could.

The practical upshot: in React, developers have to manually shield components from unnecessary re-renders, or lean on the React Compiler to do it for them. In Solid, unnecessary re-renders structurally don't exist in the first place — only the DOM node that actually depends on the changed signal gets updated.

What the benchmarks say about performance

The architectural gap shows up directly in synthetic tests. Stefan Krause's js-framework-benchmark — the most frequently cited independent frontend framework benchmark — has shown the same pattern for years: SolidJS consistently sits in the top tier of results, right next to "pure" VanillaJS with no framework at all, while React noticeably lags in scenarios with frequent fine-grained updates, large lists, and deeply nested component trees. The current state-of-Solid.js-in-2026 overview, which draws on that benchmark's data, confirms this. According to Boundev's analysis, in scenarios typical of js-framework-benchmark — creating, updating, and deleting thousands of rows — SolidJS beats React on runtime performance by roughly 50-70%. Worth flagging right away: that's not a universal constant that applies "to any website," it's the result of synthetic, update-heavy tests where the gap between fine-grained reactivity and the virtual DOM is at its most visible.

On real production interfaces the picture is more modest: most of the time budget there goes to network requests, images, and third-party JS rather than DOM diffing, so the gap tends to be much smaller than in the lab. The React Compiler (more on that below) narrows it further still.

Bundle size

Fine-grained reactivity gives SolidJS another side benefit: Solid's compiler turns JSX into direct DOM instructions without needing to ship a virtual-DOM diffing engine at runtime, so the framework itself ends up noticeably lighter. According to the state-of-Solid.js-in-2026 overview, Solid's core weighs around 7.6 KB minified and gzipped, versus roughly 45 KB for React + ReactDOM combined, 38 KB for Vue, and 85+ KB for Angular. The same source, citing a case study from Radware, gives a real production example: for a feature-comparable application, the SolidJS bundle came in around 80 KB versus roughly 290 KB for React. The independent framework-benchmarks.as93.net project paints a similar picture — it builds an identical app across different frameworks specifically to compare bundle sizes fairly, and there the gzipped size of a typical weather app built with Solid came out to about 9 KB.

For projects where fast first load on slow networks and weak devices actually matters, these kilobytes translate directly into milliseconds of Time to Interactive rather than staying a nice number in a report.

React Compiler: React strikes back

It would be unfair to describe React the way it looked in 2023. On October 7, 2025, the React team announced the release of React Compiler 1.0 — a build-time compiler that automatically inserts memoization across the component tree, taking over work that used to be done manually with useMemo, useCallback, and React.memo. According to that same official announcement, on real products like the Meta Quest Store the compiler delivered up to a 12% improvement on initial load and cross-page navigation, and sped up individual interactions by more than 2.5x — with neutral memory consumption. By 2026, the React Compiler is considered default practice for new React projects, and its rules are baked directly into the recommended eslint-plugin-react-hooks preset.

This doesn't erase the fundamental architectural difference — the React Compiler still operates on top of the "re-execute the whole component, but avoid redundant work through memoization" model rather than fine-grained signals. But it meaningfully narrows the practical gap in production, and it takes a big chunk of manual optimization off the developer's plate — optimization that used to be a common source of bugs from forgotten dependencies in useMemo/useCallback arrays.

Developer experience: signals are pleasant, but not without surprises

Solid's syntax is deliberately React-like — JSX, hook-like primitives (createSignal, createEffect, createMemo), a component-based approach — so the transition for a React developer feels a lot softer than, say, switching to Vue with its templates and SFCs. But a model without component re-rendering brings its own set of gotchas you won't find in React.

The main source of beginner mistakes is prop destructuring. In React, const { name } = props is standard practice. In Solid, props are implemented via getters specifically to enable fine-grained reactivity, so destructuring props "at the door" of a component breaks the reactive link and freezes the value at the moment of the first call. A rundown of SolidJS's practical pitfalls lists several other non-obvious traps: calling an arbitrary function inside createEffect implicitly subscribes the effect to every signal that function reads (which sometimes calls for wrapping it in untrack), directives are awkward to reuse across files because of how the TypeScript compiler handles them, and resource primitives don't support partial updates of nested fields — changing a single object property recreates the whole thing and triggers dependent effects unnecessarily. Nothing fatal, but it takes time to get used to, and none of it is particularly intuitive if your background is purely React.

On the plus side, there are noticeably fewer React-specific constraints to worry about: you don't need to remember the "rules of hooks" (no conditional or looped hook calls), because Solid's primitives aren't tied to call order inside a render, and a component that runs only once eliminates an entire class of stale-closure bugs that plague useEffect.

TypeScript deserves its own mention, and here Solid has a genuinely objective structural edge. Solid is written in TypeScript from the ground up, and types for all its primitives (createSignal, createEffect, createMemo, JSX components) ship directly inside the solid-js package — I checked its package.json directly via the npm registry, and it has a "types": "types/index.d.ts" field pointing to bundled declarations; there's simply no separate @types/solid-js package in the registry. React's situation is different: its own package.json has no types field at all — typings live in a separate @types/react package, which React.dev itself describes as sourced from DefinitelyTyped, meaning it's community-maintained rather than maintained by the React team directly. In practice, that means React's types can temporarily fall out of sync with the runtime when new versions ship (a common example being delays in typing new hooks), whereas for Solid, types and runtime are always the same version by construction, because they're literally the same package.

Ecosystem and market: where React wins decisively

In terms of ecosystem reach and maturity, React is still in a league of its own — there isn't much to argue about here, the gap in its favor is measured in orders of magnitude.

Developer surveys. According to State of JavaScript 2025, React remains the most-used frontend framework: 83.6% of respondents use it at work, compared to about 10% for SolidJS. At the same time, Solid has held the highest satisfaction rating among frameworks for five years running — people who've tried it rarely want to go back to alternatives, but the overwhelming majority of the market is still on React. That popularity has a flip side: the same survey records complaints about React's complexity and about the monetization strategy around Next.js/Vercel — one of the most frequently mentioned pain points in respondent comments. The numbers back this up: Next.js satisfaction in the survey dropped from 68% to 55% amid growing complexity around Server Components and the App Router, and React itself, despite 98% usage reach, draws the most specific complaints about individual APIs — useEffect got the lowest satisfaction rating of any hook, with dependency-array issues coming in second (21% dissatisfied). React's popularity isn't going anywhere, it remains dominant — but satisfaction with working on it, and with its flagship meta-framework, has dropped noticeably.

GitHub. The gap in community size is also visible in the repositories: facebook/react has around 247,000 stars versus roughly 35,700 for solidjs/solid — nearly a sevenfold difference, reflecting the scale of the contributor base and outside attention.

Job market. The gap in job listings is even starker than the one in GitHub stars: React has effectively become a baseline requirement in frontend job postings at large companies, while the SolidJS developer community remains niche — there are an order of magnitude fewer openings, and hiring mostly happens through niche boards like SolidJS Jobs Listing rather than mainstream job boards.

Ready-made solutions. React has Next.js, Remix/React Router, React Native for mobile, dozens of mature UI kit libraries, and years' worth of ready-made answers on Stack Overflow — things that in Solid often need to be solved yourself or wait for the ecosystem to catch up. SolidStart, the Next.js-equivalent meta-framework for Solid, is still under active development: as of early 2026 it's at SolidStart 2.0.0-alpha.2, while the Next.js ecosystem has years of production usage under its belt at companies like Vercel, Nike, TikTok, and dozens of others. For teams that care about predictable hiring, API stability, and a wide range of ready-made integrations, this is a heavy — and often decisive — argument in favor of React, regardless of the competitor's architectural advantages.

Native apps deserve a separate note: React has React Native, while Solid has no direct framework equivalent for mobile development. It does have an alternative on a different stack that covers more than just desktop, though. SolidJS pairs well with Tauri — a Rust wrapper that renders a frontend built with any web framework, but instead of bundling Chromium like Electron does, it uses the system's WebView, resulting in dramatically smaller binaries and lower memory usage. With the stable release of Tauri 2.0, the framework stopped being a purely desktop tool: it now officially supports iOS and Android from the same codebase — WKWebView on iOS, the system Android WebView on Android — meaning that, in theory, a single Solid app can be built for all five platforms at once (Windows, macOS, Linux, iOS, Android). The mobile side is younger than the desktop side and still a bit rough around the edges — there are quirks around plugins, app signing, and webview peculiarities — but it's already usable in production, not just a proof of concept. There are official and community-maintained Tauri + Solid starter templates (riipandi/tauri-start-solid, ZanzyTHEbar/SolidJSTauri, and for mobile builds specifically SolidJSTauriMobile), and a walkthrough of the Rust + SolidJS + Tauri combo for cross-platform apps has also been published on LogRocket Blog. Electron is still unmatched in desktop maturity and reach for now — roughly 4.95 million weekly downloads for electron from npm versus about 1.96 million for @tauri-apps/cli (npm registry data for July 13-19, 2026) — and it's still slightly ahead on GitHub stars too (122K versus 109K for tauri-apps/tauri). But the gap is noticeably narrower than on the web, and the fact that Tauri has grown from a niche desktop project into a full-fledged cross-platform alternative to both Electron and React Native within a couple of years makes Solid + Tauri a genuinely fast-growing choice in exactly the area where SolidJS used to have a structural gap versus React.

SolidJS 2.0 and SolidStart: where the framework is headed

The project isn't standing still. The SolidJS 2.0 beta shipped on May 15, 2026 — the first major release to make async a first-class citizen directly inside the reactive graph: computations can now return promises directly, and the framework handles suspending and resuming on its own, without wrapping everything in Suspense. The release also drops the old Suspense in favor of a simpler Loading that's only responsible for a subtree's initial readiness, adds action() and createOptimisticStore for mutations, and now batches signal writes at the microtask level — a refactor that the framework's creator, Ryan Carniato, defends as the outcome of more than a year spent analyzing alternative approaches, even though part of the community finds the new split-phase createEffect API clunkier at first glance.

The current stable line is 1.9.x (according to the state-of-Solid.js-in-2026 overview, the latest version is 1.9.11), so the 2.0 beta isn't yet recommended for new production projects. But the very fact that the framework keeps getting architectural investment, rather than freezing on a "stable but neglected" 1.x, is a good sign for its continued viability.

Bottom line: when to pick what

Technically, SolidJS really is better than React in a lot of ways: fine-grained reactivity without a virtual DOM eliminates an entire class of re-render problems, synthetic benchmarks like js-framework-benchmark consistently put Solid on par with vanilla JS, and the bundle ends up several times lighter for comparable functionality. All of that is a direct consequence of compiling JSX into fine-grained DOM operations, not empty fan enthusiasm.

But "technically better" and "the right choice for your team right now" are different questions. The React Compiler has meaningfully narrowed the practical performance gap in production, and React's ecosystem, job market, and sheer volume of ready-made solutions remain an order of magnitude bigger than Solid's. That directly affects development speed and how easy it is to hire for the project — a factor that matters for years, not one sprint. If you're starting a personal or small commercial project where performance and a small bundle really matter, and flexibility in picking libraries isn't a priority — SolidJS is a mature, well-justified choice today. If you're working on a large team, depend on a wide range of ready-made integrations, need React Native, or simply don't want to spend weeks hunting for a rare specialist later — React remains the far safer bet, and the React Compiler only strengthens that bet.

Sources

minimal css framework

Tertiumnon — Sat, 07 Jun 2025 05:17:44 +0000

Cooking with TypeScript enums

Tertiumnon — Wed, 26 Mar 2025 16:42:35 +0000

Periodically I hear that something wrong with TypeScript enums. But if you understand how it works - it's not an issue for you.

The usage is very simple:

enum Role {
  None = 0,
  Moderator = 1,
  Admin = 2,
}

And we have a good news here - we can use string values in TypeScript! For instance, C# enums can't work with string values.

enum UserRole {
  None = "",
  Moderator = "moderator",
  Admin = "admin",
}

Pros and cons of enums

Excessive JavaScript code after compilation

I think the claim that TypeScript enums produce excessive JavaScript code is somewhat overstated. Have you ever wondered how much code your compiler generates? I highly doubt it. But when it comes to types, you somehow think differently. Don't you find that strange?

Let's take a look on generated JS code.

var Role;
(function (Role) {
    Role[Role["None"] = 0] = "None";
    Role[Role["Moderator"] = 1] = "Moderator";
    Role[Role["Admin"] = 2] = "Admin";
})(Role || (exports.Role = Role = {}));

Looks ugly but it doesn't produce any "terrible" effects.

We can continue our investigation. Let's create a file with enum and a file with type.

export type RoleType = "" | "moderator" | "admin";

And than we can import both files to apply values from both kinds.

import { UserRole } from './enum';
import { RoleType } from './type';

const role = UserRole.Moderator;
const roleType: RoleType = "moderator";

The result in JS will be:

var enum_1 = require("./enum");

var role = enum_1.UserRole.Moderator;
var roleType = "moderator";

You see here that enum produce a variable with values but type don't. It means that enum don't repeat itself. It's an Object with properties.

Let's create a class - another TypeScript feature.

export class User {
  name: string;
  email: string;
}

And you will get the next compiled JS code:

var User = /** @class */ (function () {
    function User() {
    }
    return User;
}());

Looks ugly too, isn't it? More code, more problems? I don't think so!

I worked with many projects and teams, and you should know that very common problems are:

Over-complicated code (ignoring all principles of clean coding)
Inefficient code (CPU and memory loading)
Environment issues (caching invalidation, network loading, etc.)
Legacy dependencies (security issues, difficulties with upgrading)

Non-obviousness of usage

The most common example of incorrect use of enums is shown in the code below.

enum UserRole {
  Admin,
  Moderator,
}

And this is a real problem here. Problem for those who don't understand some JS and TS nuances.

// you will get a logically incorrect result
const ROLES_VALUES = Object.values(UserRole); // ["Admin", "Moderator", 0, 1]

This is the reason why we always must use values for enums.

A good part of `enums`

Enums can help you create arrays and objects that we might need in other parts of the project.

const isRoleValueCorrect = (value: UserRole) => ROLE_VALUES.includes(value);

Or you can create options for select:

const options = Object.entries(UserRole).map(arr => ({label: arr[0], value: arr[1]}));
/*
[{
  "label": "None",
  "value": ""
}, {
  "label": "Moderator",
  "value": "moderator"
}, {
  "label": "Admin",
  "value": "admin"
}] 
 */

Conclusions

TypeScript enums is not a "bad" feature.

In some case it's confusing but only if you don't understand how to work with that.

This is convenient if you want to create related data structures.

A minimum of books that should be read by a novice or experienced programmer

Tertiumnon — Wed, 26 Mar 2025 12:57:17 +0000

Below a small list of books that I can personally recommend for reading to all programmers, including beginners. As it usually happens that I bought, I sell it.

Computer Science fundamentals

Computer Science Distilled (Wladston Ferreira Filho)

This is an super-"based" book which is well-suited for beginners, particularly for those who have no specialized education.

Harvard CS50 video course

This is not a book, but perhaps the best that you can find for training a base. This is a magnificent Harvard course, on the example of which you will understand why people seek to get to study in places such as Harvard. You can watch this course online absolutely free.

Also, you can earn a certificate on edx.org or on the Harvard website. The course is regularly updated, so if you started, it is better to finish in the same year.

Programming

Object-Oriented Thought Process (Matt Weisfeld)

I would describe this book as the initial one for those who want to use the OOP in their work. I know that this book is not very popular, but it personally helped me in due time to "set up" some concepts in my head.

Head First Design Patterns (Eric Freeman, Elisabeth Robson, Bert Bates, Kathy Sierra)

There are two versions of these books - one of them contains illustrations for better understanding. Understanding the patterns will allow you to structure various approaches in your head and communicate in the same language with other programmers, choosing solutions for certain problems.

Clean Code (Robert Martin)

In the book you will find a set of rules that will help you write understandable for yourself and, which is much more important in large companies, a code understood for other programmers. The sooner you read this book, the better.

Test Driven Development: By Example (Kent Beck)

Sometimes programmers neglect testing (which is bad). The book will inspire you to write tests, or at least give food for thought.

Algorithms and data structures

Grokking Algorithms (Aditya Y. Bhargava)

The book gives basic ideas about the algorithms and data structures. The book is loved by many for its simplicity, with which the author explains key principles. If you read, understand and implement everything that is in this book, then you should not have problems with the next book. It is recommended to read the updated (fixed) version of the book.

Cracking the Coding Interview (Gayle Laakmann McDowell)

Essentially, this book is intended for those who are going through interviews at major technology companies. A lot of material is dedicated to the main section – algorithmic.

System Design

System Design (Alex Xu)

A well-structured book that is often recommended for reading before undergoing interviews. Numerous diagrams, describing various 'IT-related' things, by the same author can be found online.

High Load

Designing Data-Intensive Applications (Martin Kleppmann)

Famous "book with the boar", one of the fundamental books for a programmer who wants to proudly call themselves a Software Engineer.

Management

Software Engineering at Google (Titus Winters, Tom Manshreck, Hyrum Wright)

The book provides general insights into development at tech giants like Google. You can learn how to be a good manager, hire engineers and evaluate their performance, test, scale, and decide on tools to use – a lot of useful content.

Agile Estimating and Planning (Mike Cohn)

In my opinion, the book is somewhat verbose. However, it contains very detailed descriptions of team interactions working with Agile methodology, which you'll start to understand and use better.

Afterword

It would be interesting to see your minimum set of books in the comments. If there are any remarks, I'll try to improve the article or publish an updated version later.

You don't need Redux

Tertiumnon — Wed, 12 Mar 2025 11:11:55 +0000

As you're likely aware, Dan Abramov published a post titled "You Might Not Need Redux" back in 2016. Yet, here we are in 2025, and it appears that many projects and job postings haven't adapted. Sadly, not much has changed.

The Yandex expert in the video below demonstrates that you can thrive without using Redux.

Please, be aware the video contains Russian language and auto-generated English subtitles.

DEV Community: Tertiumnon

package.json, package-lock.json, and Semantic Versioning: Why You Need to Understand This

Why versioning exists in the first place

Semantic versioning: MAJOR.MINOR.PATCH

Versioning in package.json: operators and symbols

Exact version (no symbols)

Caret (^) — safe updates within major version

Tilde (~) — only patches

Greater than (>) and less than (<)

Equals (=)

Asterisk (*)

Combining operators

package-lock.json: why it's your lifesaver

The horror story: when versioning breaks your project

Different lock files for different package managers

Common developer mistakes

Mistake 1: Adding lock file to .gitignore

Mistake 2: Manually editing lock files

Mistake 3: Exact versions everywhere

Mistake 4: Wrong lock file handling during branch merges

Mistake 5: Using npm install instead of npm ci in CI/CD

How to properly work with versioning

Final checklist

Sources

SolidJS vs React (2026)

Reactivity: signals vs the virtual DOM

What the benchmarks say about performance

Bundle size

React Compiler: React strikes back

Developer experience: signals are pleasant, but not without surprises

Ecosystem and market: where React wins decisively

SolidJS 2.0 and SolidStart: where the framework is headed

Bottom line: when to pick what

Sources

minimal css framework

Cooking with TypeScript enums

Pros and cons of enums

Excessive JavaScript code after compilation

Non-obviousness of usage

A good part of enums

Conclusions

A minimum of books that should be read by a novice or experienced programmer

Computer Science fundamentals

Computer Science Distilled (Wladston Ferreira Filho)

Harvard CS50 video course

Programming

Object-Oriented Thought Process (Matt Weisfeld)

Head First Design Patterns (Eric Freeman, Elisabeth Robson, Bert Bates, Kathy Sierra)

Clean Code (Robert Martin)

Test Driven Development: By Example (Kent Beck)

Algorithms and data structures

Grokking Algorithms (Aditya Y. Bhargava)

Cracking the Coding Interview (Gayle Laakmann McDowell)

System Design

System Design (Alex Xu)

High Load

Designing Data-Intensive Applications (Martin Kleppmann)

Management

Software Engineering at Google (Titus Winters, Tom Manshreck, Hyrum Wright)

Agile Estimating and Planning (Mike Cohn)

Afterword

You don't need Redux

A good part of `enums`