Libraries that have both CommonJs and AMD definitions

I have a library that has the following definition:

(function (root, factory) {
    if (typeof module === "object" && module.exports) {
        // Node, or CommonJS-Like environments
        module.exports = factory(require("lodash"), require("conduitjs"), this);
    } else if (typeof define === "function" && define.amd) {
        // AMD. Register as an anonymous module.
        define(["lodash", "conduitjs"], function (_, Conduit) {
            return factory(_, Conduit, root);
        });
    } else {
        // Browser globals
        root.postal = factory(root._, root.Conduit, root);
    }
}(this, function (_, Conduit, global, undefined)

When WebPack detects these definitions, it includes both (webpack)/buildin/amd-options.js and (webpack)/buildin/module.js. I get that its doing this because both CommonJs and AMD are at play, but I don't get why they are needed in the first place given that WebPack supports these (with my normal modules) without the need for this.

Try with imports loader

require('imports?define=>false!postal');

From https://webpack.github.io/docs/shimming-modules.html#fixing-broken-module-styles

Ok I'll give this a go. Whats the down side of doing this though? I'm guessing its on by default for a reason?

It's not this code fragment that causes this modules to be included. This UMD code fragment compiles down to:

var r,e;
!function(n,i){
  "object"==typeof t&&t.exports?
  t.exports=i(o(1),o(2),this):
  (
    r=[o(1),o(2)],
    e=function(t,o){return i(t,o,n)}.apply(null,r),
    !(void 0!==e&&(t.exports=e))
  )
}(this,function(){

})

Try --display-reasons to show the reason of a module inclusion.

(webpack)/buildin/amd-options.js is included when you use define.amd.
(webpack)/buildin/module.js is included when you use module

Both are pretty small modules.

Great! I don't have a particularly big problem with it, just trying to understand how and why everything running/put together.

Since there will always be modules in your codebase which use AMD or CommonJS I think it's pretty common that both buildins end up in your bundle.

Is it possible to tell the system, "try and just use AMD or CommonJS, but if you need to use both, thats ok"? It seems like the intelligent thing that webpack could do (note thats not to imply its easy).

I have the same problem with the EventEmitter2 NPM module.
Wouldn't be feasible to handle all NPM modules by default as commonjs modules?
This is the code I'm talking about:
https://github.com/asyncly/EventEmitter2/blob/master/lib/eventemitter2.js#L560

Blame the module...

Here is a config that disables AMD for all node_modules:

module: {
  loaders: [
    { test: /node_modules/, loader: "imports?define=>undefined" }
  ]
}

Wouldn't be feasible to handle all NPM modules by default as commonjs modules?

That's not possible. There are AMD modules on npm.

@jhnns

@jhnns npm is strictly for CJS format, there might be modules that try to support other formats, but modules that doesn't support CJS doesn't make sense in npm, they're just invalid

https://github.com/mozilla/source-map is in AMD, but with amdefine. webpack will thread it as AMD.

perf(css): drop what a declaration, a slot or a query already says

perf(css): drop what a declaration, a slot or a query already says (#…

Navigation Menu

Repository navigation

Libraries that have both CommonJs and AMD definitions #333

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Libraries that have both CommonJs and AMD definitions #333

Description

Activity

agundermann commented on Jul 1, 2014

avanderhoorn commented on Jul 1, 2014

sokra commented on Jul 1, 2014

avanderhoorn commented on Jul 1, 2014

jhnns commented on Jul 2, 2014

avanderhoorn commented on Jul 2, 2014

nickdima commented on Sep 10, 2014

sokra commented on Sep 10, 2014

jhnns commented on Sep 12, 2014

medikoo commented on Sep 15, 2014

sokra commented on Sep 15, 2014

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions