Omlet Docs
Search
K

Next steps

Steps to get the most use of Omlet

Scanning more repositories

With Omlet, you can scan multiple repositories into the same workspace, and it will automatically correlate components defined in one repo that are used in another. No duplicate components or double counting of usage!
To scan another repo, add @omlet/cli as a dependency to a new repo and run npx omlet analyze.
You'll now see component usage for a new project appear in the "Core vs. Custom Adoption by Project" chart in the Analytics dashboard.

Tagging components

You can apply additional tags to your components to generate in-depth analysis from charts and understand a component's dependency from the dependency tree view. For example, if you have depreciated components, you can tag them and track if their usage decreases over time. To add more tags, head to the "Manage Tags" page from the workspace menu in the top left corner. You can create more tags and apply them to your components on this page.
Here are some use cases for adding custom tags:
  • You have multiple component libraries or a legacy library you want to track.
  • You want to track the usage of components that you want to deprecate.
  • You may want to categorize Icons, Pages, and other types.
  • You categorize components by complexity levels, such as Atoms, Molecules, and Patterns.
  • You want to track components that can be candidates for your reusable component library.

Ignoring components

Omlet supplies sensible default configurations to ignore certain files such as Storybook stories documentation or test files. 👇
  • **/node_modules/**
  • **/*.d.ts
  • **/stories/**/*
  • **/.storybook/**/*
  • **/*.stories.{jsx,tsx,js,ts}
  • **/*.{spec,test}.{jsx,tsx,js,ts}
  • **/{__test__,tests}/**/*.{jsx,tsx,js,ts}
You can also pass a glob pattern to the --ignore option in the analyze CLI command to filter out directories, files, or components you do not want to track.
You can pass multiple ignore glob patterns: --ignore 'glob/one/' --ignore 'glob/two/'

Setting up regular scans

Once you are happy with the results, set up Omlet CLI to run as part of your build process or schedule regular CLI runs. This way, you will see changes in usage over time and track the new components being added, removed, or updated.
To run Omlet CLI in an automated environment, pass the Omlet access token to an environment variable:
  1. 1.
    You can generate an access token by running: npx omlet login --print-token (or npx @omlet/cli login --print-token if you are running it outside of your repository)
  2. 2.
    Then, set the access token to an environment variable named OMLET_TOKEN. Omlet CLI will automatically search for this specific environment variable.

Map aliases in a configuration file

If you have aliases set up in a tsconfig file or a bundler such as Webpack, Vite, or Babel, Omlet may have trouble resolving import paths from aliases out of the box. Luckily, Omlet can resolve them if you define these aliases in a config file.
To define the aliases, first, create a .omletrc.js file at the root of the repository.
If you have a tsconfig file already, simply point to it using the tsconfigPath field:
{
...
"tsconfigPath": "tsconfig.frontend.json"
}
If you have aliases setup in a bundler, define mapping between your aliases and paths in the aliases field:
{
...
"aliases": {
"@components/*": ["src/components/*"],
"@icons": ["src/icons/index.tsx"]
}
}
You can also set your CLI parameters and options to fine-tune the results and store these in the configuration file, such as ignore and input. Go to the CLI Documentation page to find out more.
Did you run into any errors or issues?
Check out the Troubleshoot page for common errors and how to resolve them.