Package com.liferay.frontend.js.loader.modules.extender.npm

Defines the interfaces and utilities for the NPM registry facility.

See: Description

Interface Summary

Interface	Description
JSBundle	Represents an OSGi bundle containing NPM packages and modules.
JSBundleAsset	Provides contents of a JSBundleObject.
JSBundleObject	Provides an object related to the NPM description model that can be directly referenced by its unique ID.
JSBundleProcessor	Processes an OSGi bundle to find NPM packages and modules inside it and make them available for the NPMRegistry to track them.
JSModule	Represents an NPM module inside a JSBundle.
JSPackage	Represents an NPM package inside a JSBundle.
JSResolvableBundleAsset	Represents a JSBundleAsset that is selected/resolved from a pool of equivalent objects of the same type.
NPMRegistry
NPMResolver

Class Summary

Class	Description
JSModuleAlias
JSPackageDependency	Represents an NPM package dependency (i.e., another NPM package).
ModuleNameUtil	Provides utility methods to manipulate module names.

Package com.liferay.frontend.js.loader.modules.extender.npm Description

Defines the interfaces and utilities for the NPM registry facility. Interfaces and classes here define a model for describing NPM packages and modules so they can be tracked by the com.liferay.frontend.js.loader.modules.extender.internal.npm.NPMRegistry.

In addition, the JSBundleProcessor interface provides a way to extend the portal by deploying OSGi components that analyze bundles in search for NPM packages and modules.

A brief overview of the NPM model is provided defining the following concepts:

• bundle: an OSGi bundle containing one or more NPM packages. Bundles have a symbolic name and an ID assigned by OSGi (usually a number).
• package: an NPM package containing several JS modules and described by a package.json file. Packages may depend on other packages. Packages have a name and version that uniquely identifies them.
• module: a self contained executable unit that may depend on other modules. Modules always live inside packages. Modules have a name, but they depend on their owner package to be accessed.
• dependency: a directed relation between two modules or between two packages. Note that all module dependencies are resolved in the context of the package that contains the depending module. For example, if package P1 at version 1.0.0 depends on package P2 at version 2.1.0, and the module M1 in package P1 depends on module M2 on package P2, the reference to M2 from M1 will be resolved traversing the dependency from P1 version 1.0.0 to P2 version 2.1.0.

In addition to the previous concepts defined by NPM, the portal also has important concepts:

• package ID: the string that univocally identifies an NPM package deployed inside the portal. It is composed by the ID of the bundle containing the package and the package name and version (e.g., 625/isarray@1.0.0).
• module ID: the string that univocally identifies an NPM module deployed inside the portal. It is composed by the ID of the package containing the module and the module name (e.g., 625/isarray@1.0.0/lib/index).
• resolved module: the unique reference module used by copies of the same NPM module. Since more than one copy of a specific NPM module can be deployed to the portal in different OSGi bundles, the NPM module copies must be resolved to one unique reference module (selected among ones available).
• resolved module ID: the ID of the reference module used by copies of the same module. Once the copies of the same module are resolved to a unique reference module, its ID can be simplified and no longer needs to contain the bundle ID. This is because there's no longer a need to distinguish between different bundles. Thus, the resolved module ID is defined based on the package name and version (e.g., isarray@1.0.0/lib/index.