Skip to content

oks-ui 1.2.2: what changed and why, checked against 1.2.1

Published · Updated · Last reviewed · by Omkar Sahu

An inbox list with red and blue count badges on the icons and a 1.2.2 version tag, showing the Badge fix in the release.
ShareXLinkedIn
On this page
  1. Badge accepts a number for content
  2. The MIT license now ships in the package
  3. The bug-report link works
  4. Results
  5. Upgrading
  6. Check your own project
  7. Limits
Updated 9 October 2026. This release note originally said what changed in oks-ui 1.2.2. This version adds why, and shows it: I installed oks-ui 1.2.1 and 1.2.2 side by side and checked each change, with the reasons from the project's changelog. All three held. The before-and-after results are in a table below.

oks-ui 1.2.2 is available on npm. It is a small release with two changes you can feel and one you cannot see. Nothing was removed and no behaviour changed at runtime, so upgrading is safe. I checked that: the package exports 465 names in 1.2.1 and the same 465 in 1.2.2.

npm install oks-ui@^1.2.2

Badge accepts a number for content

The most common use of a badge is a count: unread messages, items in a cart, open tasks. Until now, passing that count straight to content was a TypeScript error, even though it worked at runtime.

import { Badge } from "oks-ui/badge";
import "oks-ui/badge.css";

export const UnreadCount = ({ count }: { count: number }) => {
  return (
    <Badge content={count} color="danger">
      <span>Inbox</span>
    </Badge>
  );
};

The cause was in the props type. Badge extends the standard HTML attributes, and the HTML content attribute is a string. The two definitions were intersected, which narrowed content down to string. In 1.2.2 the props type leaves out the HTML attribute, so content can be a number or any node again. If you worked around the error with String(count) or a type assertion, you can delete that now.

Only TypeScript users were affected. In plain JavaScript the number always rendered correctly.

Why it mattered, and how I checked. A count is what a badge is for, so the error hit nearly every real use. I compiled the code above in strict TypeScript against both versions:

  • 1.2.1: error TS2322, "Type 'number' is not assignable to type 'string | ...'", pointing at content.
  • 1.2.2: it compiled with no output.

I also read the type definitions. In 1.2.1 the props were declared as Omit<HTMLAttributes<HTMLSpanElement>, "color" | "children">, which keeps the HTML content attribute and its string type. In 1.2.2 the list is "color" | "children" | "content", which is exactly the fix described above.

And I checked the other half of the claim, that this was a typing problem only. I told TypeScript to look away and rendered <Badge content={5}> from 1.2.1 in a browser: the 5 appeared next to "Inbox". So nothing was ever wrong at runtime, and String(count) was never needed for the page, only for the compiler.

The same Badge code compiled against oks-ui 1.2.1, which prints a type error, and against 1.2.2, which prints nothing.

The same code and the same compiler. Left: 1.2.1. Right: 1.2.2.

The MIT license now ships in the package

oks-ui has declared the MIT license in package.json from the start, but the package did not contain a license file. The MIT license asks that its text and the copyright notice travel with the code, so the file was missing where it mattered most. From 1.2.2 the LICENSE file is included in every install, under node_modules/oks-ui/LICENSE. The terms have not changed: you can use oks-ui in personal and commercial projects for free.

Why it mattered, and how I checked. The MIT license is a short permission with one condition: the license text and copyright notice must be included with copies of the software. A license field in package.json names the license but is not its text. Reading the contents of the published packages, the 1.2.1 package has two files at its top level, package.json and README.md. The 1.2.2 package has three: LICENSE, package.json and README.md. That is the whole change, and it is the file that lets anyone who installs oks-ui see the terms inside the package itself.

Advertisement

The npm page for a package has a link for reporting bugs. For oks-ui it pointed at a GitHub issues page that does not exist, because the source repository is private. It now points at the FAQ page, and the maintainer email is listed alongside it.

Why it mattered, and how I checked. A dead link on a package's page tells a visitor that nobody is looking. I requested the address that 1.2.1 listed, github.com/OKS-ORG/fork-oks-ui-v1/issues, and GitHub answered 404. I requested the page the bugs field points to in 1.2.2, www.oks-ui.com/faq/, and it answered 200. The 1.2.2 package.json also carries the maintainer's email address, which is the other half of the fix. This is a small change, but it is the way a person reaches the project when something is wrong.

Results

A table of before and after results for oks-ui 1.2.1 and 1.2.2: the Badge type check, the props type, the runtime result, the package files, the bugs link and the exports.

What I measured.

Upgrading

Install 1.2.2 and run your type check. If you had a cast or a String(count) around a Badge count, it is no longer needed and is safe to remove. Nothing else needs to change. The full list is in the changelog, and every release from 1.0.4 onward is described the same way.

Check your own project

If you use TypeScript, this short script lists the exports that disappeared between two versions of a package, which is how I confirmed that nothing was removed. It needs the two versions installed under different names, for example npm i oks-ui-old@npm:oks-ui@1.2.1 oks-ui-new@npm:oks-ui@1.2.2.

// node compare-exports.mjs oks-ui-old oks-ui-new
import { readFileSync } from "node:fs";
const names = (pkg) => {
  const text = readFileSync(`node_modules/${pkg}/dist/index.d.ts`, "utf8");
  const out = new Set();
  for (const block of text.matchAll(/export \{([^}]*)\}/gs)) {
    for (const part of block[1].split(",")) {
      const item = part.trim().replace(/^type\s+/, "");
      const alias = item.match(/ as (\w+)/);
      out.add(alias ? alias[1] : item.split(/\s+/)[0]);
    }
  }
  return out;
};
const [oldPkg, newPkg] = process.argv.slice(2);
const before = names(oldPkg), after = names(newPkg);
console.log(`${before.size} exports before, ${after.size} after`);
console.log("removed:", [...before].filter((n) => n && !after.has(n)));
console.log("added:  ", [...after].filter((n) => n && !before.has(n)));

For 1.2.1 against 1.2.2 it printed 465 exports before, 465 after, nothing removed and nothing added. It only reads the main type file of the package, so it does not see changes inside a subpath such as oks-ui/badge, which is where this release's fix lives.

Limits

  • I tested with TypeScript 7 in strict mode, one component, and one browser for the runtime check.
  • The bugs link and the email are metadata. I checked that the pages answer; I did not test the email address.
  • The license check shows the file is present. It is not legal advice about what the license permits.
Advertisement

Omkar Sahu

I'm a front-end engineer based in Hyderabad, India, with more than 17 years of professional experience. I spent 12 years as a senior front-end developer, designing and building websites, and I have worked as a full-stack developer since 2022. I created oks-ui, a React component library with no runtime dependencies, and I write and maintain this site.

More about Omkar Sahu · All posts

Was this post helpful?

ShareXLinkedIn