admin管理员组文章数量:1415684
In my web applications, I have many JS files that I include in the HTML body. They define many symbols that I can use directly in <script>
elements. Now, I need to use these applications inside a quite old web engine (the traditional MS WebView, which in practice means IE11), but my JS uses a lot of (relatively) new syntax (mainly arrow functions () =>
). I managed to configure Webpack and Babel to translate the code, but I lose visibility of symbols unless I explicitly add the export
keyword or assign them to corresponding members of the global window
object. Although it's a simple (and, I hope, harmless) code change, I would like to avoid it. Is there a way to instruct Webpack/Babel to preserve symbol visibility as it happens with plain JS scripts in HTML?
In my web applications, I have many JS files that I include in the HTML body. They define many symbols that I can use directly in <script>
elements. Now, I need to use these applications inside a quite old web engine (the traditional MS WebView, which in practice means IE11), but my JS uses a lot of (relatively) new syntax (mainly arrow functions () =>
). I managed to configure Webpack and Babel to translate the code, but I lose visibility of symbols unless I explicitly add the export
keyword or assign them to corresponding members of the global window
object. Although it's a simple (and, I hope, harmless) code change, I would like to avoid it. Is there a way to instruct Webpack/Babel to preserve symbol visibility as it happens with plain JS scripts in HTML?
1 Answer
Reset to default 1In short, not really.
I'll save you the "global variables are a bad idea" spiel and get straight to the technical aspects.
In order to define a globarl variable, you need to define it at the module level (among other requirements which I'm skipping).
However, in order to work, Webpack wraps every module in a big ol' function, which means that any declared variables are defined within a function scope, not the global scope.
For the vast majority of engineers, this behavior of Webpack is not just a side effect... it's a major reason to use a bundler in the first place.
As you've already noted, the way to sidestep this feature is to add properties to the window
object, e.g. window.myGlobal =
.
Now, there is actually one exception to all of this. If a module is defining a library which is intended to be "exported" as a global variable (for example, jQuery), you can use output: { library: "variableName" }
.
So, taking the example straight from the linked docs:
webpack.config.js
module.exports = {
// …
entry: './src/index.js',
output: {
library: 'MyLibrary',
},
};
src/index.js
export function hello(name) {
console.log(`hello ${name}`);
}
index.html
<script src="https://example./path/to/my-library.js"></script>
<script>
MyLibrary.hello('webpack');
</script>
If you have multiple modules like this, then you can return an array in your webpack.config.js
:
module.exports = [{
// …
entry: './src/lib/oneLib.js',
output: {
library: '$OneLib',
},
},{
// …
entry: './src/lib/twoLib.js',
output: {
library: '$TwoLib',
},
}];
index.html
<script src="https://example./path/to/oneLib.js"></script>
<script src="https://example./path/to/twoLib.js"></script>
<script>
$OneLib.foo();
$TwoLib.bar();
</script>
If you take this approach, then you'd probably want to avoid directly importing these libraries in your other modules, as this would cause code duplication. Just use them as globals (again, like jQuery).
本文标签: javascriptPreserving original global namespace in transpiled JavaScripStack Overflow
版权声明:本文标题:javascript - Preserving original global namespace in transpiled JavaScrip - Stack Overflow 内容由网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:http://www.betaflare.com/web/1745212645a2647979.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
target: ['web', 'es5']
, in babel.config.jstargets: ['ie 11'],
. My target is IE11 – Giuseppe Guerrini Commented Feb 11 at 17:09