Distribution Output Target

The dist type is to generate the component(s) as a reusable library that can be self-lazy loading, such as Family. When creating a distribution, the project's package.json will also have to be updated. However, the generated bundle is tree-shakable, ensuring that only imported components will end up in the build.

outputTargets: [
  {
    type: 'dist',
  },
];

Config

collectionDir

The collectionDir config specifies the output directory within the distribution directory where the transpiled output of Rindo components will be written.

This option defaults to collection when omitted from a Rindo configuration file.

dir

The dir config specifies the public distribution directory. This directory is commonly the dist directory found within npm packages. This directory is built and rebuilt directly from the source files. Additionally, since this is a build target, all files will be deleted and rebuilt after each build, so it's best to always copy source files into this directory. It's recommended that this directory not be committed to a repository.

This option defaults to dist when omitted from a Rindo configuration file.

empty

By default, before each build the dir directory will be emptied of all files. To prevent this directory from being emptied, change this value to false.

This flag defaults to true when omitted from a Rindo configuration file.

isPrimaryPackageOutputTarget

default: false

If true, this output target will be used to validate package.json fields for your project's distribution. See the overview of primary package output target validation for more information.

transformAliasedImportPathsInCollection

default: true

This option will allow path aliases defined in a project's tsconfig.json to be transformed into relative paths in the code output under the collectionDir subdirectory for this output target. This does not affect imports for external packages.

An example of path transformation could look something like:

// Source code
import * as utils from '@utils';

// Output code
import * as utils from '../path/to/utils';

tip

If using the dist-collection output target directly, the same result can be achieved using the transformAliasedImportPaths flag on the target's config.

esmLoaderPath

default: /dist/loader

Provide a custom path for the ESM loader directory, containing files you can import in an initiation script within your application to register all your components for lazy loading. Read more about the loader directory in the section below.

If you don't use a custom exports map, users would have to import the loader script via:

import { defineCustomElements } from 'rindo-library/dist/loader';

By setting esmLoaderPath to e.g. ../loader you can shorten or rename the import path to:

import { defineCustomElements } from 'rindo-library/loader';

Publishing

Next you can publish your library to Node Package Manager (NPM). For more information about setting up the package.json file, and publishing, see: Publishing A Component Library.

Loader

The dist output target generates a loader directory that exports setNonce, applyPolyfills and defineCustomElements helper functions when imported within an ESM context. This allows you to register all components of your library to be used in your project in an application setup script, e.g.:

import { applyPolyfills, defineCustomElements, setNonce } from 'rindo-library/loader';

// Will set the `nonce` attribute for all scripts/style tags
// i.e. will run styleTag.setAttribute('nonce', 'r4nd0m')
// Obviously, you should use the nonce generated by your server
setNonce('r4nd0m');

applyPolyfills().then(() => {
  defineCustomElements();
});

This is an alternative approach to e.g. loading the components directly through a script tag as mentioned below. Read more about setNonce and when to set it in our guide on Content Security Policy Nonces.