Please do not break the API

[Kugeleis]

With version 0.28.0 the API endpoint registerColorScheme vanished. Apparently it was split into valueColorScheme and binColorScheme.

Frankly, this is not good style. A widely accepted convention is not too break an API within minor version jumps. You might either keep a compatibility endpoint or add a versioned API.

[telecasterer]

Sorry, and you're right - removing registerColorScheme with no warning and no transition was a mistake. The change was definitely needed, but I should have deprecated and/or shimmed it on my end

For info starting with 0.30.0, wafermap will always deprecate before it removes. A deprecated function keeps working for a full minor release but will log a console notice the first time it's called, saying what to use instead, and editors should hopefully show its name struck through. Removal then happens in the next minor release, and a tests in the library block that release if anything deprecated is still exported, so it can't slip.

0.30.0 is the first release to use this: it deprecates 78 exports, which will be removed in 0.31.0.

https://github.com/wafertools/.github/discussions/4#discussion-10821451

Why deprecate so many at once:

wafermap exported far more than applications actually need. When I checked what a complete app (tsmap) uses, it came to 18 of 106 functions. The rest were internal helpers, a low-level drawing pipeline that renderWaferMap and renderWaferGallery have replaced, and chart builders from before the Insights tab drew those charts itself.

Cutting back to what applications reasonably can need/use will hopefully make the API much easier to keep stable from here.

If you rely on anything in the deprecated list, please say so here or open an issue before 0.31.0 and I'll look at keeping it or providing a replacement.

In the interest of being upfront: 0.30.0 still removes a few options outright rather than deprecating them first, most notably passBins on the analysis and render functions. Keeping that option meant a yield figure and its findings could quietly use different pass bins, which is a correctness problemI didn't want to leave in place for another release. Each removal is listed
under Breaking in the changelog:

https://github.com/wafertools/wafermap/blob/main/CHANGELOG.md#0300--2026-09-15

A note on versioning: wafermap is still pre-1.0, and it follows the semver convention for 0.x of putting breaking
changes only in minor releases (0.28.0, 0.30.0), never in patches. What was missing was notice before
something disappeared, and that's what the deprecation release now provides.

Thanks again for the feedback

[Kugeleis]

Thanks for your work and the extensive answer. Currently I use this and pinned it to be safe now ;)

import { buildWaferMap, registerValueColorScheme } from "https://esm.sh/@wafertools/wafermap@0.29.0";
import { renderWaferMap } from "https://esm.sh/@wafertools/wafermap@0.29.0/render";
import { analyzeWaferMap } from "https://esm.sh/@wafertools/wafermap@0.29.0/stats";

But I did not explore the API much further.

[telecasterer]

I'm glad the library is getting some use, feedback is always very welcome. It's useful to know what people are doing with wafermap and tsmap and especially what they think is missing or needs improving.

For info I'm reviewing the wafermap 0.30.0 deprecations and removals again today - I was probably a bit over zealous so some will be likely be reversed in a patch release coming tomorrow.

re: pinning to be safe, that's of course a very good idea before testing a new version in your code, but bear in mind most releases do include important fixes, improvements and features, so try to check the newer releases when you can.

If your wafermap data is file based you could always load it in the tsmap app or the tsmap online version to have a quick play with the latest wafermap releases (tsmap is always updated and released when there's a new wafermap release).

https://wafertools.github.io/tsmap/

[Kugeleis]

Thanks. As you might guess this is nothing I do as a hobby ;) Our wafermap analysis workflow is quite tailored to our data landscape. Hence the library is what helps me building an app.

[telecasterer]

Quick follow-up in case it's useful: everything in your snippet (buildWaferMap, registerValueColorScheme, renderWaferMap, analyzeWaferMap) is unchanged in the latest release, 0.30.1, and none of it is deprecated. Nothing you import is affected by the 0.31.0 removals either.

I'd recommend moving off the 0.29.0 pin: 0.30.1 includes a security fix for how names from data files are displayed, and 0.29.0 is affected.

Two things from 0.30.0 and 0.30.1 on that you might notice:

• Bin colours now follow the bin number, so each bin has the same colour in every lot. Bin maps will look different from 0.29.0.
• If you pass passBins to analyzeWaferMap or renderWaferMap, it's now ignored with a console warning. Set it once on buildWaferMap and everything downstream uses it.

Details are in the 0.30.0 announcement and What's New.

[telecasterer]

0.31.0 is out, and it removes the exports deprecated in 0.30.x. Everything in your snippet (buildWaferMap, registerValueColorScheme, renderWaferMap, analyzeWaferMap) is still there, so moving to @0.31.0 needs no import changes.

Two changes worth checking against your own data:

• Values the STDF V4 format can't hold are now treated as missing rather than plotted: bins outside 0–32767, X/Y outside ±32767, and test results that aren't finite numbers. result.warnings lists them (input-values-outside-stdf).
• If you set downloadFilename, it's now a prefix: <name>_W05_hard-bin.png.

If you're still on 0.29.0, the notes in my previous reply apply too. The full list of removals is in the 0.31.0 update.