
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.2Badge 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 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.
The bug-report link works
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

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

