Reputation: 5248
I am working on a project with laravel that uses (as it is the default) webpack to bundle its assets. In there, I do have a dependency on a package that in turn has dependencies to lodash and deepdash.
Since deepdash is provided as a mixin for lodash, the usage of it is (as per the docs) like this:
// load Lodash if you need it
const _ = require('lodash');
//mixin all the methods into Lodash object
require('deepdash')(_);
or, if you want to use ES6 syntax (at least that is my understanding), it would translate to:
import _ from 'lodash';
import deepdash from 'deepdash';
deepdash(_);
Having done that, I am trying to use webpack to create a bundle now to be used in the browser. My problem is, that for some reason it appears that webpack replaces the import of lodash with some "__webpack_require__" magic functionality, which leads to lodash not being a function anymore, and the browser says this:
To better demonstrate my problem I created a demo github repo with just trying to webpack deepdash and lodash: ArSn/webpack-deepdash Here is the line that the browser complains about: https://github.com/ArSn/webpack-deepdash/blob/master/dist/main.js#L17219
I have played around a lot with adding babel configuration en mass and it felt like my best shot was the plugin babel-plugin-transform-commonjs-es2015-modules. I tried that, the result was still exactly the same.
I feel like either I have a deep misunderstanding of the situation or I am missing just one tiny little thing. I can however for the life of me not figure out which one it is and what.
Side notes:
Upvotes: 7
Views: 3870
Reputation: 8490
Pointing explicitly to the deepdash main module works for me when running one of the examples from the deepdash website:
import _ from 'lodash';
import deepdash from 'deepdash/deepdash';
deepdash(_);
Webpack uses the browser
entry as default:
"main": "deepdash.js",
"module": "es/standalone.js",
"browser": "browser/deepdash.min.js",
This will not work for Webpack and static imports - because there is nothing really "exported".
Also: Commonly these entries do not point to minified builds. These are usually only for CDN use cases and not for bundlers.
On the contrary 'deepdash/deepdash.js'
exports the decorator function.
The deepdash-es
build basically does the same thing except that it uses es6 exports. Maybe this is the way that treeshaking can work out of the box. Not sure about at that...
In order to circumvent the "browser" issue - the author of deepdash could just simply amend it to use "deepdash.js" or remove it:
https://github.com/defunctzombie/package-browser-field-spec
If your module is pure javascript and can run in both client and server environments, then you do not need a browser field.
Upvotes: 4