Gathering detailed insights and metrics for multi-expose-loader
Gathering detailed insights and metrics for multi-expose-loader
Gathering detailed insights and metrics for multi-expose-loader
Gathering detailed insights and metrics for multi-expose-loader
npm install multi-expose-loader
Typescript
Module System
Min. Node Version
Node Version
NPM Version
JavaScript (100%)
Total Downloads
0
Last Day
0
Last Week
0
Last Month
0
Last Year
0
MIT License
2 Stars
17 Commits
1 Watchers
4 Branches
2 Contributors
Updated on Jul 13, 2021
Latest Version
1.0.2
Package Id
multi-expose-loader@1.0.2
Unpacked Size
11.23 kB
Size
4.32 kB
File Count
9
NPM Version
6.14.8
Node Version
12.19.0
Cumulative downloads
Total Downloads
Last Day
0%
NaN
Compared to previous day
Last Week
0%
NaN
Compared to previous week
Last Month
0%
NaN
Compared to previous month
Last Year
0%
NaN
Compared to previous year
1
3
While I was working on an upgrade project that had a lot of "plain-old JavaScript" files that using a lot of global JS variables, I noticed that not all JS files could be upgraded to ES6.
So I had to use the Expose loader for webpack to continue providing these global variables. Unfortunately, I was not able to port all code to ES6 modules using only ES6 default exports, which the export loader could handle. Some modules export members, which has to be placed in the global scope too. So I searched for a webpack loader placing members in the global scope.
Found Expose Members loader for webpack, but this, somewhat older, contribution by @davidpelayo did not meet my requirements. So I decided to write a loader that can expose both the default export and member export to the global scope.
Requirement: Expose jquery to globals $ and jQuery
1module: { 2 rules: [{ 3 "test": "jquery", 4 "use": [{ "loader": "multi-expose-loader", "options": "$,jQuery" }] 5 }] 6}
Solution: Separate multiple exports with a comma.
Requirement: Expose exports member1 and member2 from module example.js to globals member1 and member2
1module: { 2 rules: [{ 3 "test": "./example.js", 4 "use": [{ "loader": "multi-expose-loader", "options": "#member1,#member2" }] 5 }] 6}
Solution: Indicate members with a leading #
Requirement: Expose exports member1 and member2 from module example.js to globals alias1 and alias2
1module: { 2 rules: [{ 3 "test": "./example.js", 4 "use": [{ "loader": "multi-expose-loader", "options": "alias1:#member1,alias2:#member2" }] 5 }] 6}
Solution: Seperate alias and member with a colon
Requirement: Expose to namespace
1module: { 2 rules: [{ 3 "test": "./example.js", 4 "use": [{ "loader": "multi-expose-loader", "options": "namespace1.alias1:#member1,namespace2.alias2:#member2" }] 5 }] 6}
Solution: Give the point separated path to the alias
Of course, the configuration can also be made via import or require. Examples:
1import 'multi-expose-loader?$,jQuery!jquery'; 2 3require('multi-expose-loader?#namespace1.member1,alias2:#member2!./example.js');
Unlike the expose-loader, only one webpack module is generated. For example, it looks like this:
1/* 63 */ 2/***/ (function(module, exports, __webpack_require__) { 3 4"use strict"; 5/* WEBPACK VAR INJECTION */(function(global) { 6 7var __multi_expose_loader_exports = __webpack_require__(64); 8global["alias1"] = __multi_expose_loader_exports.member1; 9if (!global["namespace2"]) global["namespace2"] = {}; 10global["namespace2"]["alias2"] = __multi_expose_loader_exports.member2; 11globalmodule.exports = global["global1"] = global["global2"] = __multi_expose_loader_exports; 12/* WEBPACK VAR INJECTION */}.call(exports, __webpack_require__(3))) 13 14/***/ })
The peer dependencies are webpack 2 and 3. I think it also works in 4, but without testing I added this webpack version not to the peers.
No vulnerabilities found.
Reason
security policy file detected
Details
Reason
no dangerous workflow patterns detected
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
SAST tool detected but not run on all commits
Details
Reason
8 existing vulnerabilities detected
Details
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
Found 1/12 approved changesets -- score normalized to 0
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Score
Last Scanned on 2025-06-30
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More