The `bit-loader-shimmer` package provides a plugin for `bit-bundler`, enabling detailed control over how non-modular or legacy JavaScript modules are integrated into a modern bundler environment. Currently at version 1.1.0, this package allows developers to define 'shims' for specific modules, dictating their file paths, dependencies (imports), and what they expose to other modules or the global scope (exports). This is particularly useful for handling libraries that expect global variables, require a specific load order, or do not conform to CommonJS or ES module patterns. It offers granular configuration options, such as aliasing imports and exports, linking to global objects, and resolving modules by name or direct path. While a specific release cadence isn't published, the 1.x versioning suggests stability. Its key differentiator lies in its comprehensive API for managing the module environment for legacy scripts, bridging the gap between traditional script inclusion and modular bundling, especially within the `bit-bundler` ecosystem.
npm install bit-loader-shimmerVerified import paths — ran on the pinned version, not inferred.
This quickstart demonstrates how to configure `bit-loader-shimmer` to handle legacy libraries like jQuery and Bootstrap, managing their imports, exports, and global interactions within a `bit-bundler` setup.
Carefully trace expected global names and module dependencies. Use the `as` property for local aliases within the shimmed module's scope and `global` for managing properties on the `window` or global object. Validate loading order and variable availability.
Prioritize using modern, modular versions of libraries when available. Use shimming primarily for smaller, isolated legacy scripts, or to bridge specific global dependencies for otherwise modular code. Consider refactoring legacy code if shimming becomes overly complex.
Always use `path.resolve()` with `__dirname` or absolute paths for clarity and reliability, especially when dealing with module paths that might be ambiguous, or use the `name` option for modules resolvable via npm or similar registries.
Ensure the shim for jQuery (or similar dependency) is loaded before the dependent module and that its `exports` configuration correctly includes `global: ['$']` (and potentially `name: 'window.$'`) to make the variable available.
Verify the `path` property contains the correct, absolute, or relative-to-config-file path to the shimmed file. If using `name`, ensure the module is installed and its main entry point or sub-path is correctly specified according to Node.js resolution rules.
Review the `exports` array for the shimmed module, ensuring that the `as`, `name`, and `global` properties correctly map the internal variable or global object property to the desired export name.