Troubleshooting imports

Component builds

Approach

As with most development issues, in general a good approach to troubleshooting build problems is to isolate the problem.

For component library builds the simplest way to do this is to comment out components in your index file, to work out which component is causing the problem:

// export Accordion from './Accordion';
// export AccordionToggle, { useAccordionToggle } from './AccordionToggle';
// export AccordionCollapse from './AccordionCollapse';
// export Alert from './Alert';
export Badge from './Badge';
// export Breadcrumb from './Breadcrumb';
// export BreadcrumbItem from './BreadcrumbItem';

Module not found error

If webpack reports "module not found" errors, it is usually because the module is not installed, or an alias is required to resolve it. Please refer to the File Resolution section below.

File resolution

👉

You may need to create aliases in your interplay configuration if your code requires them.

The CLI uses node module resolution to find its way around your repo, starting with your component index file for each of the packages you are imported. Sometimes the CLI can't resolve a file. This is usually due to one of the following reasons:

1. Missing npm package

The CLI follows standard node resolution to resolve imports, 'finding up' through node_modules folders from the file where the import is declared.

  • Check that any required npm dependencies have been installed
  • Check that npm modules installation paths are what you expect. Sometimes we find that an index file has been created at a level above where the installed node_modules exists.

2. Missing alias

The CLI automatically generates aliases based on the package.json files found in your repo, but if you are using other custom aliases you'll need to tell Interplay about them. You can also override the CLI's default package aliases by defining them yourself.

To do this, add a top level node called 'alias' in the CLI's interplay.json configuration file and map the local path for each alias your code requires. This path should be relative to the working directory where you are running the CLI (usually the base folder of the repo).

//interplay.config.js
"alias": {
    "@Components": "./relative/path1/here/",  //start with ./
    "@Alias2": "./relative/path2/here/",
    "package-name-here": "./relative/path3/here/"
},

Note that the mapped paths should begin "./" for relative paths.

These aliases will be used by the CLI when resolving code imports, and passed to webpack for use in bundling your code.

Please refer to the import settings documentation for more details.

3. package.json fields not set

When a code import resolves to a package name, the package.json is inspected for a main field.

  • Ensure that that a main field exists as expected in the package.json and it points to the path you expect
  • Sometimes the file specified in the main field does not yet exist locally. Ensure that any required build process for the package has been run first to generate expected local files before running the Interplay CLI.

Preset Parsing

Presets not imported

If you create preset files using the recommended format, the CLI parsing should find the instances of your components and generate preset configuration for them.

When parsing existing repo files that contain instances of your components, some instances may not be discovered or may not be converted to presets.

You can find two log files output by the CLI for further information:

.interplay/logs/summary.txt

This file contains a table for all the exports found in your component index, showing how was resolved to its source file, and any component properties that were found when parsing this source file.

.interplay/logs/presetSummary.json

This file contains an entry for each preset file parsed. If your file does not show up here then the CLI did not find your preset file - please check your presetPaths setting in interplay.config.js

For each file, counters are added for the number of instances of all the recognised components found in the preset file, which ones matched your presetRules.

For the instances that matched your preset rules, a further validation status is shown:

Imported - instance was imported as a preset.

UnknownComponent - instance was rejected because it contains a component that is not in recognised as being in component index - usually either a local formatting component (i.e. not exported from your index) or one that has been imported from a different location from where your component index resolved.