Arco Design React publishes four entry points and no bundled styles

Four entry points ship from one package

The package name is @arco-design/web-react, and the manifest routes four different consumers to four different files. `module` points at ./es/index.js for bundlers that read ES modules, `main` points at ./lib/index.js for CommonJS, `types` points at ./es/index.d.ts, and `unpkg` points at ./dist/arco.min.js, which is the file a CDN or a script tag reaches. That last field matters when you are debugging a page that behaves differently from your build: the version a browser pulls from a CDN is a different artifact from the one your bundler resolved. Installation is one command in either of the two package managers the project supports:

// with npm
npm install @arco-design/web-react

// with yarn
yarn add @arco-design/web-react

Nothing in the manifest pins a React version, so peer compatibility is something the consuming project has to verify against the documentation site rather than read off the package.

Styles are a separate import, so a missing stylesheet is silent

The library does not inject its CSS when a component renders. The published example imports the stylesheet as a side effect on its own line, and everything about the look of the components depends on that line being present:

import React from 'react';
import ReactDOM from 'react-dom';
import { Button } from '@arco-design/web-react';
import '@arco-design/web-react/dist/css/arco.css';

function App() {
  return (
    <Button type='secondary'>
      Hello World
    </Button>
  );
}

ReactDOM.render(<App />, document.getElementById('app'));

The example also mounts through ReactDOM.render rather than a createRoot call, and no alternative mounting call is published alongside it, so that line is the reference for how the library expects to be mounted. A bundler configured to ignore CSS, or an application that forgets the import, A bundler configured to ignore CSS, or an application that forgets the import, produces markup with no error and no warning, which is the worst failure shape for a design system: the components exist and nothing tells you why they look wrong. The dark mode documentation is separate from the component documentation for the same reason, since a dark theme is a stylesheet decision rather than a prop. The build side matches that split, with a dedicated css build target and a separate script that runs the project's css-variables file, so the variables your theme overrides are generated artifacts rather than hand written values.

Design Lab is the recommended theme route, less-loader the other

Theme customization has exactly two supported routes, and the project marks one of them as recommended. The first is less-loader, which means you compile your own variables into the stylesheet from a Less source. The second is Design Lab, a separate web platform where themes are created and managed, and the project labels it the recommended one. Underneath both routes sit the same extensive design tokens, which are the values you override to build your own theme rather than patching component internals. The README also points at a Figma component library, so the token set has a design side counterpart, and at a marketplace for customized modules that lets teams reuse what they already built. What the project does not publish is a token list in the repository itself, so a token by token audit means going to the documentation site.

Icons and the version stamp run before the build

Publishing is a chain of steps rather than a single compile, and two of them are easy to miss. The prepublishOnly hook runs three commands in order: it regenerates the version, it builds the icons, and only then does it build the package. The icon step is a separate script of its own, and the repository keeps an icon directory at the root,

"prepublishOnly": "yarn generate-version && yarn icon && yarn build",
"build:icon": "arco-scripts build:icon",

which tells you the icon set is a build product rather than a set of hand maintained files. The same script builds your own project, so the component build and the hook build are two independent chains: the package build script calls a component build and then separate hook builds for the dist, es and cjs outputs. If you fork the repository, that ordering is the part to respect, because a missing icon or version step produces a package that installs cleanly and looks wrong later.

The browser floor is Chrome 49, Firefox 31, Safari 31, Edge 16

The support table in the README is a set of minimum versions, not a set of badges to admire. Firefox 31, Chrome 49, Safari 31, Opera 36 and the last two versions of Electron, with Edge named at version 16, which leaves Internet Explorer out of the picture entirely. Read that as a floor the components are expected to run on rather than as a list of versions the team tests continuously, and note the shape of it: those minimums are old enough that the target is deliberately broad. For a design system that also has to run on a wide range of machines, that is a deliberate choice, and it is why the TypeScript sources and the token driven theming matter more than any single component. The build targets live in a browserslist file at the root of the repository, so the transpilation target is declared once and reused.

Storybook runs on 6006 and the documentation site on 9000

The repository carries both a component workbench and a documentation site, and the scripts give each a fixed port. The demo script starts Storybook on port 6006, and the site development script runs the site on port 9000, and the combined start script runs both at once with a concurrency helper:

"demo": "start-storybook -p 6006",
"dev:site": "arco-scripts dev:site --port 9000",

In the tree that shows up as a .storybook directory, a stories directory and a site directory, with a netlify configuration file for the deployed documentation. There is also a .codesandbox directory, which is the sandbox wiring for the example snippets people copy from the docs. The eslint and stylelint scripts cover the tests and components directories, and the repository has prettier and husky configuration alongside them, so a fork gets the same checks the maintainers run.

The React package is one piece of a wider platform

The ecosystem table in the README puts the React library next to five related products, and the split explains what the repository does not contain. There is a separate Vue component library built on the same design system, so this repository is not where the Vue line is maintained. Design Lab is the theme platform, a separate marketplace is where customized modules are reused, Icon Box manages icons as its own service, and Arco Pro is a starting point for building applications from scratch. Alongside those, the useful links section points at bundler plugins in a separate arco-plugins repository and at an Awesome Arco list. For an engineer, the practical consequence is that theme tooling and icon tooling are separate products with separate release cycles, and integrating only the React package leaves both of them outside your dependency list.

2.66.16 is current, and the 2026 releases are not monthly

The version in package.json is 2.66.16, and it matches the newest release, which was published on 2026-07-14. Before that came 2.66.15 on 2026-05-08 and 2.66.14 on 2026-04-17, so the cadence across three 2026 releases stretches from April to July rather than following a monthly train. The last push to the default branch landed on 2026-08-24, the repository is not archived, and the license is MIT. Documentation for contributors points at a code of conduct file and a contributing guide, and the project maintains a Simplified Chinese readme alongside the English one, which is the clearest sign of where its user base sits. Changelogs are produced by a script rather than written by hand, so release notes for a specific version are worth reading before an upgrade rather than inferred from the version number.

Editorial conclusion

Pick Arco Design React when you want a TypeScript React library with a token based theme you can drive from less-loader or from Design Lab, and when you are willing to own the stylesheet import and the build steps that produce it. Pass on it when your bundler cannot handle a package that needs a CSS import on the entry file, or when you need browser support below the stated floors, which start at Edge 16, Chrome 49, Firefox 31 and Safari 31. Before you commit, check three things: whether 2.66.16, the version in package.json and the newest release, carries the fix you need, whether your icons are built separately through the icon script, and whether the Vue line in the ecosystem table is a distraction or a plan.

Frequently asked questions

Official sources

1. arco-design/arco-design on GitHub
2. License: MIT
3. Project website
4. README
5. Releases