<p dir="auto"><strong>Do you want to request a <em>feature</em> or report a <em>bug</em>?</strong><br>
Bug</p>
<p dir="auto"><strong>What is the current behavior?</strong><br>
I'm migrating an application from Webpack 1 to 2, where we on and off have updated code from <code class="notranslate">module.exports</code> to ES2015 <code class="notranslate">import/export</code>. Here and there, we got a mix. When cases like this occurs, Webpack seem to export/import modules in a non-backwards compatible way.<br>
In the example repo I've made, I've been able to reproduce the bug.<br>
<code class="notranslate">__WEBPACK_IMPORTED_MODULE_0__deps_a__</code> has object set. However, <code class="notranslate">__WEBPACK_IMPORTED_MODULE_0__deps_a__["default"]</code> is <code class="notranslate">undefined</code>.</p>
<p dir="auto"><strong>If the current behavior is a bug, please provide the steps to reproduce.</strong></p>
<ol dir="auto">
<li>Here's a branch with the issue: <a href="https://github.com/jouni-kantola/webpack-output-by-build-type/tree/import-module-exports-mix">https://github.com/jouni-kantola/webpack-output-by-build-type/tree/import-module-exports-mix</a></li>
<li><code class="notranslate">npm run serve</code> (to build, which doesn't cause errors: <code class="notranslate">npm run build</code>)</li>
<li>I've made comments in the code where the bug is occurs and what can be done in the code itself to work around it</li>
</ol>
<p dir="auto"><strong>What is the expected behavior?</strong><br>
It would be easier to migrate old code running with Webpack 1 ifmixing <code class="notranslate">imports/module.export</code> works. However, I fully understand if you feel it's up to the applications to not do weird things.</p>
<p dir="auto"><strong>Please mention other relevant information such as the browser version, Node.js version, Operating System and programming language.</strong><br>
OS: Windows 10 + MacOS Sierra 10.12.1<br>
Node: Windows 10 &gt; Node v6.4.0, MacOS &gt; Node v6.8.0<br>
Deps:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="&quot;devDependencies&quot;: {
    &quot;babel-core&quot;: &quot;^6.21.0&quot;,
    &quot;babel-loader&quot;: &quot;^6.2.10&quot;,
    &quot;babel-preset-env&quot;: &quot;^1.1.4&quot;,
    &quot;html-webpack-plugin&quot;: &quot;^2.24.1&quot;,
    &quot;webpack&quot;: &quot;^2.2.0-rc.3&quot;,
    &quot;webpack-dev-server&quot;: &quot;^2.2.0-rc.0&quot;
  }"><pre class="notranslate"><code class="notranslate">"devDependencies": {
    "babel-core": "^6.21.0",
    "babel-loader": "^6.2.10",
    "babel-preset-env": "^1.1.4",
    "html-webpack-plugin": "^2.24.1",
    "webpack": "^2.2.0-rc.3",
    "webpack-dev-server": "^2.2.0-rc.0"
  }
</code></pre></div>
<p dir="auto">With the <code class="notranslate">2.2.0-rc.0</code> release, any module that has an <code class="notranslate">include</code> declaration is also considered a harmony module and does not go through the commonjs module interop.</p>
<p dir="auto">However, such modules are still allowed to modify the <code class="notranslate">module</code> object's <code class="notranslate">exports</code>, so they can still make commonjs exports.</p>
<p dir="auto">This is a breaking change when a file has an <code class="notranslate">import</code> but exports using <code class="notranslate">module.exports</code>, and is <code class="notranslate">import</code>ed via a default import declaration. The <code class="notranslate">module.exports</code> object is treated as if it was a namespace, and accessing <code class="notranslate">default</code> (most likely) results in <code class="notranslate">undefined</code>.</p>
<p dir="auto">On real ES2015 modules, <code class="notranslate">module</code> or <code class="notranslate">exports</code> will no longer exist, so these variables should not be accessible (accessing should throw <code class="notranslate">ReferenceError</code> unless the user declares them in their own scope).</p>
<p dir="auto">If you're going with this breaking change, I'd say you should go all the way <g-emoji class="g-emoji" alias="smile" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/1f604.png">😄</g-emoji></p>
<div class="highlight highlight-source-js notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="// a.js
import './empty'

module.exports = { foo () {} } // `module` should be ReferenceError instead"><pre class="notranslate"><span class="pl-c">// a.js</span>
<span class="pl-k">import</span> <span class="pl-s">'./empty'</span>

<span class="pl-smi">module</span><span class="pl-kos">.</span><span class="pl-c1">exports</span> <span class="pl-c1">=</span> <span class="pl-kos">{</span> <span class="pl-en">foo</span> <span class="pl-kos">(</span><span class="pl-kos">)</span> <span class="pl-kos">{</span><span class="pl-kos">}</span> <span class="pl-kos">}</span> <span class="pl-c">// `module` should be ReferenceError instead</span></pre></div>
<div class="highlight highlight-source-js notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="// empty.js"><pre class="notranslate"><span class="pl-c">// empty.js</span></pre></div>
<div class="highlight highlight-source-js notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="// b.js
import a from './a'
a.foo() // TypeError as of 2.2.0-rc.0"><pre class="notranslate"><span class="pl-c">// b.js</span>
<span class="pl-k">import</span> <span class="pl-s1">a</span> <span class="pl-k">from</span> <span class="pl-s">'./a'</span>
<span class="pl-s1">a</span><span class="pl-kos">.</span><span class="pl-en">foo</span><span class="pl-kos">(</span><span class="pl-kos">)</span> <span class="pl-c">// TypeError as of 2.2.0-rc.0</span></pre></div>