# Ant Design: sideEffects says *.css, and the package ships three entry points

> antd is the React component library behind Ant Design, published under the name antd at version 6.6.5. Its manifest tells bundlers to keep only its CSS, ships CommonJS, ES module and CDN builds side by side, and documents four different package managers, which is where most of the decisions a consumer actually makes live.

**ant-design/ant-design** — An enterprise-class UI design language and React UI library

- Repository: https://github.com/ant-design/ant-design
- Website: https://ant.design
- Stars: 99,615 · Forks: 54,711
- Language: TypeScript
- License: MIT
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/ant-design-ant-design

## sideEffects marks only *.css, so tree shaking is a question about styles

The manifest published to npm declares exactly one thing as having side effects: the glob *.css. Everything else in the package is treated as side-effect free, which tells a bundler it may drop JavaScript modules that look unused. The consequence is narrow and worth holding onto: the stylesheets are the part the bundler has been told to keep.

Three files at the repository root make the same decision visible from the other side. There is index.js, index-with-locales.js, and index-style-only.js, so a consuming application can choose whether translation bundles and style payloads arrive with the import. Consequence for the reader: a build pipeline that strips CSS imports is removing the one category this package asks bundlers to preserve, and the failure arrives as a page with missing styles rather than as a build error you can catch in CI.

## main, module and unpkg are three different libraries in one package

package.json points main at lib/index.js, module at es/index.js, unpkg at dist/antd.min.js, and typings at es/index.d.ts. The files array ships four directories, dist, es, lib, and locale, plus BUG_VERSIONS.json at the package root.

Two things follow from that layout. TypeScript declarations exist only under es/, so a project that resolves types from a CommonJS build path has to be told to look in es/ for them. And a package carrying three delivery shapes leaves the choice to your tooling: a prebuilt minified file served from a CDN, or a module graph a bundler can prune. Consequence for the reader: the resolution you get is decided by your bundler's module and main fields rather than by anything written in the README, so two teams installing the same version can end up loading different builds without noticing.

## The dist step raises the Node heap to 4 GB before it will finish

The build script is two commands: it runs the compile step, then runs the dist step under cross-env with NODE_OPTIONS set to --max-old-space-size=4096. Underneath, compile is an alias for compileOnly, which is a clean followed by antd-tools run compile, and the clean script is a rimraf over es, lib, coverage, locale, dist, report.html, artifacts.zip and oss-artifacts.zip. A precompile hook runs prestart before any of it.

Consequence for the reader: anyone building this repository from source should expect a packaging step that explicitly raises the Node heap to 4 GB, and a clean that deletes generated output before recompiling. On a memory-constrained machine that number is the first thing to check, because the repository states it plainly rather than leaving you to discover it as an out-of-memory crash.

## Four package managers for users, npm for contributors

The install section gives four commands, and they differ only in the tool they invoke:

```bash
npm install antd
yarn add antd
pnpm add antd
bun add antd
```

None carries a version range. The package name is antd, not ant-design, which is the first thing to get right when you are reading a tutorial written against a different name. There is also a script called clean:lockfiles that removes package-lock.json and yarn.lock, so the repository treats the package manager as a local choice rather than a pinned one. The development section then uses npm install and npm start after a clone. Consequence for the reader: four documented ways in and no stated preference for the project itself, so the tool your team already uses is a legitimate choice, but the lockfile script exists because mixing two of them leaves a tree neither one expects.

## The browser table says last 2 versions, which is a policy without a floor

The environment section names modern browsers, server-side rendering, and Electron. Below that sits a support table whose header row is Edge, Firefox, Chrome, Safari, and Electron, and whose single data row reads last 2 versions.

A rolling last-2 policy has no floor written into it. There is no oldest supported version, no minimum, and no date. A browser that stops receiving updates eventually falls outside the promise without any number on your side changing, and you get no signal that it happened. The table itself is also offset by one column: the data row has five cells and its first cell repeats the browser name rather than a version range. Consequence for the reader: you can rely on current browsers and on server-side rendering, and you cannot cite a specific minimum browser version from this repository, because none is recorded.

## Four Jest configs and a second tsconfig for an older React

The top level holds .jest.js, .jest.image.js, .jest.node.js, and .jest.site.js, with jest-puppeteer.config.js beside them. The names say the test surface is split by kind, so the component tests, the image tests, the Node-environment tests, and the documentation site tests are not one process with one setup.

Next to those files sits tsconfig-old-react.json, a second TypeScript configuration whose only stated purpose in its name is type-checking against an older React than the current one. The build toolchain around it is equally plural: a father build config, a dumi site config, an mako bundler config, an antd-tools config, and an eslint flat config in mjs form.

Consequence for the reader: a bug report is easier to act on if you name which of those configurations covers the component you hit, and if you are the kind of team that pins to the newest React, tsconfig-old-react.json is the place the project already records the version skew it intends to keep supporting.

## Three releases in two weeks, a two-language changelog, and MIT

The recent release history is tight: 6.6.5 on 2026-09-20, 6.6.4 on 2026-09-14, and 6.6.3 on 2026-09-07, with the manifest version sitting at 6.6.5. That is roughly one release a week, all inside the 6.6 line, which means patch updates arrive without a major bump to plan around.

Two changelog files sit at the top level, CHANGELOG.en-US.md and CHANGELOG.zh-CN.md, so the release notes are in the repository in both languages rather than only on the site. The repository is not archived, the last push to master was on 2026-09-25, the licence is MIT, and funding runs through OpenCollective with a sponsors page and a documented process for applying to become a collaborator.

Consequence for the reader: weekly patch cadence inside one minor line is a low-friction upgrade, but it also means the question is not whether to upgrade and how far behind you can afford to sit. Reading CHANGELOG.en-US.md before a bump is the cheapest way to find out.

## Conclusion

Adopt antd when you are building a React application that wants one coherent visual language and the components in it, and you can live with a design system that makes its own opinions visible in every screen. Do not adopt it for a small site, for a Figma-to-code workflow, or expecting Material UI's component coverage, because this repository is a React package with a design system attached rather than a cross-tool design language. Before you pin a version, check three things: which of the three entry points your bundler is actually resolving, whether your React version is inside the range the six release notes imply, and whether the last-2-versions browser policy covers the floor your users need, since no minimum version is written down anywhere in the repository.

## FAQ

### How do I install Ant Design in a React project?

Install the package under the name antd, with npm install antd, yarn add antd, pnpm add antd, or bun add antd, then import components from it, for example import { Button, DatePicker } from 'antd'. The published package name is antd.

### How do I use Ant Design components in React?

Import the components you need from 'antd' and render them. The usage example in the repository imports Button and DatePicker, renders a Button with type primary and a DatePicker with a placeholder. Theme customization is built on CSS-in-JS, and the site links a Customize Theme page for the configuration options.

### How do I install Ant Design in a Next.js project?

The repository documents npm install antd, yarn add antd, pnpm add antd, and bun add antd, and lists server-side rendering under environment support. It does not document a Next.js-specific setup, so framework-level configuration for that case is not described in the README.

### Who owns Ant Design?

The code is published under the MIT licence, and the npm package manifest points funding at OpenCollective, with a sponsors page and a documented process for applying to become a collaborator. Governance documents in the repository include CODE_OF_CONDUCT.md, SECURITY.md, and contributors.json.

### What is Ant Design in React?

It is a set of React components published as the npm package antd, written in TypeScript, with internationalization for dozens of languages and theme customization based on CSS-in-JS. The current published version in the manifest is 6.6.5.

## Sources

- [Official documentation](https://ant.design)
- [Official README](https://github.com/ant-design/ant-design#readme)
- [Project repository](https://github.com/ant-design/ant-design)
- [Release notes](https://github.com/ant-design/ant-design/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ant-design-ant-design