Install

@productgenius/react is a private package. It is not published on the public npm registry, so you install it by one of two supported paths: the tarball your Product Genius contact hands you, or directly from git. Both produce the same package in node_modules.

Option 1 — the tarball

Your handoff bundle contains a packed tarball, productgenius-react-<version>.tgz. Install the file:

npm install ./productgenius-react-<version>.tgz

Use the exact filename you were given; it carries the version. npm records a file: dependency pointing at the tarball, so keep the file in the repo (or in an internal artifact store your CI can reach) if your builds need to reinstall from a clean checkout.

This is the most reproducible path: the archive already contains the built output, so installing it needs no build toolchain, no git access, and no network beyond your own storefront repo.

Option 2 — install from git

You can also install the package straight from its repository:

# latest on the default branch
npm install github:gamalon/productgenius-react

# pinned to a tag or a commit — recommended
npm install github:gamalon/productgenius-react#<tag-or-commit>

Releases are tagged vX.Y.Z, so #v1.2.3-style refs and full commit SHAs both work.

This works because the package builds itself on install: its prepare script runs the bundler, so your package manager clones the repository, installs the build's dev dependencies in a temporary directory, produces dist/, and installs the result.

Two requirements come with that:

• Repository read access. The repository is private. Whoever runs npm install — including your CI runner — needs credentials that can clone it. Ask your Product Genius contact to grant access.
• A package manager that runs prepare for git dependencies, plus git on the machine. Without the prepare step you get a package with no dist/ and imports fail.

Pin to a tag or commit rather than tracking the default branch, so an install months from now resolves to the same code. Installing from git is convenient when you would rather not pass a binary around; the tarball is the safer default for locked-down build environments.

Peer dependencies

"peerDependencies": {
  "react": "^18 || ^19",
  "react-dom": "^18 || ^19"
}

React is never bundled into the package — it uses whichever copy your storefront already has. There are no other runtime dependencies.

What you import

import {ProductGeniusFeed, ProductGeniusSearchBar} from '@productgenius/react';

import type {
  ProductGeniusFeedProps,
  PDPConfig,
  AddToCartItem,
  OnAddToCart,
  ProductGeniusSearchBarProps,
} from '@productgenius/react';

The package ships ESM and CJS builds plus TypeScript declarations, and the built entry carries a "use client" directive — so in a React Server Components host (Next.js App Router) a Server Component can import and render the components directly, with no extra client boundary of your own.

Updates

Feed and recommendation behaviour is delivered by the Product Genius bundle the component loads at runtime, not by the package. Those updates reach your storefront on the next page load, with no reinstall and no deploy.

You only take a new version of this package when the component's own surface changes — its props, the script-loading logic, or this guidance. Expect that to be rare.