Share JavaScript Code

To share code between components, create an ES6 module in an API module component and export the variables or functions that you want to share using standard JavaScript syntax. Each JavaScript file is subject to the file size limit.

An ES6 module is a JavaScript file that explicitly exports variables or functions that other modules can use. Modules make it easier to structure your code.

LWC has two patterns for sharing code:

• Create JavaScript files that export code in the same folder as the component importing the code. Import the code using a relative path. Other components can’t import this file directly. This approach supports structuring code within a component rather than sharing code with other components.
• Create an API module component (library), which is a component folder that contains one or more JavaScript files that export code. To import the code, other components use c/componentName syntax. Components can import code only from the main JavaScript file, which has the same name as the folder name. To share code from supplemental JavaScript files in the library, export the code from those files, then re-export it from the main JavaScript file. See the How to Access Exports in Supplemental JavaScript Files section.

This example uses the first pattern. Only myComponent.js can import code from utils.js and myFunction.js.

To import the code, use relative paths.

To import from the lwc module, see LWC Import Declarations.

This example is an API module component. The folder and one JavaScript file must have the same name. In this example, the name is mortgageUtils.

To import the code into other components, use c/componentName syntax.

An ES6 module can export a single default function or variable.

This export syntax also works.

To refer to the default export, the component that imports the function must choose a name in the import statement. It doesn’t have to be the name of the exported function or JavaScript file, that’s just a convention.

An ES6 module can export multiple named functions or variables.

The component that imports the functions uses the exported names.

An LWC module c/moduleName exposes only one of its moduleName files as the entry point. The entry point can be its JavaScript file or its CSS file. The LWC compiler resolves the module’s entry point in the following order.

1. If moduleName.js exists, it’s the entry point.
2. Otherwise, moduleName.css is the entry point.

If neither file is found, the compilation fails.

In this example, utils.js is the entry point of the c/utils module:

Importing a function from c/utils resolves to utils.js.

All of these imports fail:

Supplemental JavaScript files use a different file name than the component or module name. To access an export from a supplemental JavaScript file, use export from syntax to import it and re-export it in the main JavaScript file. This syntax is a combination of import and export.

For example, let’s say you want to export code from a supplemental moreUtils.js file.

In moreUtils.js, export the code.

In utils.js, this statement exports the functions and makes them available to other Lightning web components. The functions aren’t available in utils.js unless you also import them like in the first example on this page.

You can also use a wildcard to export all resources from a supplemental module.

In the component, import the functions as if they are in utils.js.

LWC doesn’t support circular imports between modules. A circular import happens when module A imports from module B, and module B imports from module A. This can happen directly or through a chain of other modules. Avoid these dependency cycles in your components and shared libraries.

When a cycle exists, one of the modules loads before its dependency finishes evaluating. Imported names from that module resolve to undefined. Symptoms vary, but common signs include:

• TypeError: X is not a function when calling an imported function.
• Cannot read properties of undefined when accessing an imported value.
• Components that render in isolation but fail when composed with others.
• Errors that appear only after a platform upgrade changes module evaluation order.

To find a cycle, trace the import statements between the failing module and its dependencies. Follow each imported module’s own imports until you either return to the starting module or exhaust the chain. A return to the starting module confirms a cycle.

For example, this pair of modules forms a direct cycle.

A cycle can also span more than two modules: c/alpha imports from c/beta, c/beta imports from c/gamma, and c/gamma imports from c/alpha.

Pick one of these patterns to break the cycle.

• Extract shared code into a third module. Move the values that both modules need into a new library, then import them from that library in both places.
• Merge the modules. If two modules are tightly coupled, combine them into one.
• Invert the dependency. Pass the dependency as a function argument or component property instead of importing it.
• Remove the unnecessary import. Cycles often appear after a refactor leaves a stale import behind.

After you remove the circular import, redeploy the affected components and confirm that the original error no longer occurs.

See Also

• Component JavaScript File
• Blog: ES6 In Depth: Modules
• Trailhead: Modern JavaScript Development: Learn about JavaScript ES6 features and what you can do with them
• MDN: export statement