Cloudscape components: a manifest that still reads 3.0.0 next to releases at 3.0.1391

The manifest reads 3.0.0 while the releases are numbered past 3.0.1391

The package.json at the root of this repository declares the name `@cloudscape-design/components` and the version `3.0.0`. The three newest releases are 3.0.1391 dated 2026-09-30, 3.0.1390 dated 2026-09-29 and 3.0.1389 dated 2026-09-28, and the last push to the default branch is dated 2026-09-24. The repository is not archived, so a mismatched version field is not a symptom of an abandoned project here. What it does mean is that the version string in the manifest and the version numbers a user installs are two different numbering schemes, and nothing in the manifest explains which one a downstream lockfile should record. The install line carries no version at all, so there is no third signal to reconcile them with:

npm install @cloudscape-design/components @cloudscape-design/global-styles

Anyone automating a pin has to pick one of those two numbers and hope it matches what they meant.

Components are reached one at a time, and the stylesheet arrives as a side effect import

One package is not enough. The install command above names two npm packages, and the example that follows digs into the first one for a single component and pulls the second one in for its stylesheet:

import Button from '@cloudscape-design/components/button';
import '@cloudscape-design/global-styles/index.css';

function App() {
  return <Button variant="primary">Click me</Button>;
}

Two details hide in that snippet. The path segment is the lower case `button` while the exported name is `Button`, so the folder and the identifier do not line up. And the CSS arrives through an ordinary side effect import from the global styles package, which puts a stylesheet on the critical path of any module that renders one of these components. Nothing here shows how to theme the components, override a token, or run them without the global stylesheet, so those three questions have no answer in the repository's own example.

One of the four Cloudscape dependencies is written as a prerelease range

The dependencies block opens with four `@cloudscape-design` packages. Three carry plain release ranges: `@cloudscape-design/collection-hooks` at `^1.0.0`, `@cloudscape-design/test-utils-core` at `^1.0.0` and `@cloudscape-design/theming-runtime` at `^1.0.0`. The fourth, `@cloudscape-design/component-toolkit`, is written as `^1.0.0-beta`, the only spot in the manifest where the project marks a piece of itself as unfinished. It is also a range every consumer of the components library resolves on install. The test helper sits under the same key as the theming runtime, so its range applies to anyone who installs the package rather than only to contributors. The drag and drop libraries follow, `@dnd-kit/core` at `^6.0.8`, `@dnd-kit/sortable` at `^7.0.2` and `@dnd-kit/utilities` at `^3.2.1`, and the entry after that begins `ace-builds`.

Five jest configs sit at the root, and only two test scripts pin the timezone

The root of the repository carries five jest config files: `jest.build-tools.config.js`, `jest.integ.config.js`, `jest.motion.config.js`, `jest.unit.config.js` and `jest.visual.config.js`. The npm scripts divide the suite five ways, and only two of them set a timezone:

"test": "TZ=UTC gulp test",
"test:unit": "TZ=UTC gulp test:unit",
"test:a11y": "gulp test:a11y",
"test:integ": "gulp test:integ",
"test:motion": "gulp test:motion"

`test:a11y`, `test:integ` and `test:motion` therefore run under whatever timezone the machine is set to, so the same commit can behave differently on a laptop and on a build server. Linting takes a different route again: `lint` expands to `npm-run-all --parallel lint:*`, which runs eslint and stylelint side by side rather than through gulp the way every test script does.

React 18 is an environment variable, not a second install

`build:react18` is the ordinary production build with one extra argument in front of it:

"build": "cross-env NODE_ENV=production gulp build",
"build:react18": "cross-env NODE_ENV=production REACT_VERSION=18 gulp build"

The development side works the same way and reuses a single webpack config file for both major versions. `start:dev` runs webpack serve against `pages/webpack.config.cjs`, and `start:react18:dev` runs that same command with `REACT_VERSION=18` added, started next to `start:watch` through `npm-run-all --parallel`. Only the integration server switches files, over to `pages/webpack.config.integ.cjs`. So the React major version is a build input that gulp and webpack resolve internally, which puts the weight of compatibility on whatever range the manifest declares rather than on anything visible in these scripts.

Styling spans four directories and stylelint only reaches two of them

Four top level directories hold styling work: `src/`, `src-themeable/`, `style-dictionary/` and `pages/`. Two of them have their own tsconfig files, `tsconfig.src-themeable.json` and `tsconfig.style-dictionary.json`, standing next to the single `tsconfig.json` that covers the rest. The stylelint script only looks at two of the four:

"lint:stylelint": "stylelint --ignore-path .gitignore '{src,pages}/**/*.{css,scss}'"

The glob covers `src` and `pages`, so a stylesheet under `src-themeable` or `style-dictionary` does not match it. Both of those trees still exist for style work, given what they are named and the fact that each has a dedicated tsconfig, so token or theme changes made there fall outside the lint pass that the root `.stylelintrc` configures.

A clone that installs runs two lifecycle commands that are not npm builtins

The manifest declares two lifecycle scripts. `prepare` runs `husky`, and the tree has a `.husky/` directory at the root, so a fresh clone that runs an install ends up with local git hooks wired into that checkout. `postinstall` runs a command called `prepare-package-lock`, whose name says it writes a lockfile rather than only reading one. Neither command is part of npm itself, so each one has to be supplied by the project's own dependency set. For a machine that runs `npm install` in a checkout before doing anything else, that is two commands executed ahead of every test and build script in the manifest, and it is worth reading before a pipeline runs it for you.

No changelog entry, and the versioning strategy sits in CONTRIBUTING.md

The root entry list has `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md`, `AGENTS.md`, `NOTICE` and a `THIRD-PARTY-LICENSES` directory, with no changelog entry among them. The README sends component API and guideline questions to the Components section of the Cloudscape website, the developer start guide to a separate page on that same site, and contribution, support model and versioning strategy questions to the in repository `CONTRIBUTING.md`. Licensing is split the same way: Apache 2.0 in the repository metadata, the same license named in the README, and in the tree a `LICENSE` file, a `NOTICE` file and a third party licenses directory. Reconstructing what changed between 3.0.1389 and 3.0.1391 means leaving the repository and reading the release page.

Editorial conclusion

Use this package when you want the React components behind AWS console style interfaces and are willing to read version numbers off the release page instead of the manifest field. Before pinning, check what the prepare-package-lock and husky lifecycle scripts do inside your own install environment, and expect the component API reference to live on cloudscape.design rather than in the repository. The prerelease toolkit range and the two test scripts without a timezone flag are the two places where this build can surprise a team that assumes a frozen dependency graph.

Frequently asked questions

Official sources

1. cloudscape-design/components on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases