Develop Reference

Shimming in Webpack

I am reading Shimming from the official docs. of Webpack, but still I'm unable to get what it means ?
As I am new to Webpack, I have also tried to do some RND, but I could not get the proper answer from that. I have few questions about Shimming which are as follow :
What is Shimming ?
What does Shimming does actually ?
Why there is need of Shimming in webpack ?
How it works ?
Pros and cons of Shimming.
If anyone knows, even few answers of the questions mentioned above, please let me know.

Some libraries depend on global variables. For example, a jQuery plugin may expect the "$" global variable to be available.
Without shimming that variable with ProvidePlugin you would get an error $ is not defined.
In simple terms shimming would replace all global $ variables in JavaScript modules with require('jquery'). In some legacy libraries you would also need to shim jQuery or window.$ because the plugin only performs a basic text replacement.
You only need shimming for libraries or any code you do not have control over. In the application modules you should import jQuery with import $ from 'jquery' and avoid global variables.

How to include lib to karma tests?

I'm trying to use external libs in tests. I added all needed links in karma.conf.js and some libs were included without any problem. But for some libs karma sets "undefined" instead of "this" when compiling they, like this:
And of course, then I have errors because of it:
What could I do wrong? Is it possible to include such lib?

In a JavaScript module, this is undefined at the top level (i.e., outside functions). Because of that, Rollup will rewrite any this references to undefined so that the resulting behaviour matches what will happen when modules are natively supported.
To solve it you can use options.context and options.moduleContext to change this behaviour. Like this: context: 'window'

WebStorm Dynamically Created Node.js Modules + Intellisense

So we have a lot of modules in our own internal Node.js code that kind of work like this:
module.exports = function(opts) {
// do some stuff with opts
return {
moduleMethod0: ...,
moduleMethod1: ...
};
}
The issue with this is that WebStorm can no longer auto-complete our modules when we use this pattern!
Is there a way to help WebStorm out here?
Edit:
It seems like WebStorm can work with JSDoc stuff. So that's a good start! I think I can actually figure this out on my own. All I gotta do is find the module and give it all the JSDoc stuff right there.
We have a helper file that instantiates our target module with the opts and then passes that around as its module export. I'll just add the JSDoc stuff there and hopefully it'll just work.

Is Browserify compatible with Polymer and/or AngularJS

I'd like to use a NodeJS library in my Polymer/AngularJS applications. To do so, I aim to run Browserify on the NodeJS module I wish to use and then reference it in a Polymer web component and also in an AngularJS controller. As far as I can tell, Browserify merely adds require() to the global namespace and so there should not have any naming conflicts.
Is there anything I'm missing or will these technologies work together?

Browserify works fine with Polymer. I normally expose modules using browserify's --standalone flag then integrate as a Polymer elements behavior.

I find out a way to use Polymer with webpack polymer-ext
If you want ues browserify with polymer, maybe you should try the same way.

As another, not so sophisticated approach that doesn't use standalone or behaviours but is maybe a bit more flexible, I've gone with defining a global variable APP. Then defining a get function that returns one of the global required modules.
eg
// in main index.html file before elements.html imported define global namespace
<script>
var APP = {};
</script>
Make a test module
// services/test.js
module.exports = {
test: function(){
console.log('imt the test function');
}
}
Then in main js file.
// main js file
(function(APP) {
var globalModules = {
test: require('./services/test')
}
APP.get = function(moduleName){
return globalModules[moduleName];
}
})(APP);
Then this can be used inside Polymer elements when required like
APP.get('test').test();
Not sure what the standpoint would be on whether this would be the "proper" way to do it but it works for what I was trying to achieve and may help someone.

Testing Custom Modules with DOH

I'm trying to build some unit tests for an old JS file/module that is out of my control.
The JS module is built using the following pattern...
var myModule = {
myMethod:function() {
}
};
I am then trying to build a DOH test harness to test this. I tried the following...
require([
"doh/runner",
"../../myModules/myModule.js"
], function(doh) {
console.log(doh);
console.log(myModule);
});
The file seems to be getting picked up fine but I can't reference anything in it. "console.log(myModule);" just returns undefined.
Anyone know how I can correctly include an external non dojo module JS file in a DOH test harness?
Thanks

Other than you shouldn’t be using DOH because it is deprecated (use Intern), there is no reason that you shouldn’t see myModule there. You are using a script address and not a module ID, which isn’t right, and you are using a relative path with a require call, which is also not right, but if either of these things were preventing the loader from finding and loading the script you are trying to load it should be throwing an error that you could see in the console. The only other possibility is you have somehow managed to build a built layer into this myModule script, in which case the entire script ends up wrapped in a closure and so using var foo will no longer define a global variable foo.

You need to declare myModule in the function callback to your require statement:
require([
"doh/runner",
"../../myModules/myModule"
], function(doh, myModule) { // <-- include myModule
console.log(doh);
console.log(myModule);
});
Just be sure that myModule.js returns your module.