Mobx: 3.1.12 breaks webpack build

Created on 9 Jun 2017  Â·  27Comments  Â·  Source: mobxjs/mobx

Working for 3.1.11, broken for 3.1.12

Webpack does not emit any errors at build time, but the code will not run:

mobx.module.js:3335 Uncaught ReferenceError: exports is not defined
    at Object.<anonymous> (mobx.module.js:3335)
    at Object.defineProperty.value (mobx.module.js:3335)
    at __webpack_require__ (bootstrap 81606c5…:19)
    at Object.defineProperty.value (gui.tsx:19) (require mobx)
    at __webpack_require__ (bootstrap 81606c5…:19)
    at Object.<anonymous> (main.tsx:5)
    at Object.setPrototypeOf.__proto__ (main.tsx:109)
    at __webpack_require__ (bootstrap 81606c5…:19)
    at module.exports (bootstrap 81606c5…:65)
    at bootstrap 81606c5…:65

The emitted code looks like this:

export { extras, Reaction, untracked, IDerivationState, Atom, BaseAtom, useStrict, isStrictModeEnabled, spy, asReference, asFlat, asStructure, asMap, isModifierDescriptor, isObservableObject, isObservableValue as isBoxedObservable, isObservableArray, ObservableMap, isObservableMap, map, transaction, observable, IObservableFactories, computed, isObservable, isComputed, extendObservable, extendShallowObservable, observe, intercept, autorun, autorunAsync, when, reaction, action, isAction, runInAction, expr, toJS, createTransformer, whyRun, isArrayLike };export default exports;

exports is not defined.

Webpack configuration excerpt:

            loaders: [
                {
                    test: /\.jsx?$/,
                    exclude: path => path.split("/").filter(x => x === "node_modules").length >= 2,
                    loader: 'babel-loader',
                    query: {
                        presets: ['es2015', 'react'],
                        plugins: ['transform-decorators-legacy', 'transform-class-properties']
                    }
                },
                {
                    test: /\.tsx?$/,
                    exclude: path => path.split("/").filter(x => x === "node_modules").length >= 2,
                    loader: 'ts-loader',
                    options: {
                        transpileOnly: true
                    }
                },

All our code is contained in a folder called node_modules, not sure if that's relevant. _Edit: probably not_

I'm guessing this is caused by https://github.com/mobxjs/mobx/commit/823b713f2f44078b4e2cd3bea94ce3082f61f011

(https://github.com/mobxjs/mobx/pull/1027) @rossipedia

Most helpful comment

Ugh... I thought I fixed this. Sorry everyone, I'll get a PR up right away to address it

All 27 comments

I confirm this issue

Same here

mobx.module.js:3378 Uncaught ReferenceError: exports is not defined
at Object.eval (mobx.module.js:3378)
at eval (mobx.module.js:3380)
at Object../node_modules/mobx/lib/mobx.module.js (vendor.js:1)
at p (vendor.js:1)
at t (vendor.js:1)
at React__default (index.js:2)
at eval (index.js:5)
at Object../node_modules/mobx-react/index.js (vendor.js:1)
at p (vendor.js:1)
at t (vendor.js:1)

I can confirm this issue.

I'm having the same problem.

Same problem :(

Confirmed latest release broken in webpack 2.x

same here

Same problem with webpack build, but with slightly different message:

SyntaxError: Use of reserved word 'class'
at webpack:///~/mobx/lib/mobx.module.js:8:0

I also confirm this.

Same problem here

Ugh... I thought I fixed this. Sorry everyone, I'll get a PR up right away to address it

I also confirm this problem!

I can confirm that [email protected] fixes this issue for me.

Phew. Sorry guys! Anybody wants to volunteer to run a webpack 1 & webpack 2 build & run to the test suite? (Sad that this is even needed...)

I was thinking a script that runs through a small webpack build in a temp directory, and then executes the resulting bundle file to make sure there aren't any runtime errors

Works now on my setup (on webpack 2)! thanks for the quick fix.

Sorry guys, this still seems busted even with 3.1.13 in certain cases.

We're using create-react-app. With 3.1.11 doing a production webpack build works without any errors. 3.1.13 fails to compile with the following (note, this only effects the production build since uglifyjs is barfing):

Failed to compile.

static/js/main.ff27121a.js from UglifyJs
Unexpected token: name (BaseAtom) [./~/mobx/lib/mobx.module.js:8,0][static/js/main.ff27121a.js:52583,6]

@lvpro, thats another issue, see https://github.com/mobxjs/mobx-react/issues/272

Have the same issue with my production build in create-react-app

static/js/main.f1c66bd9.js from UglifyJs
Unexpected token: name (BaseAtom) [./~/mobx/lib/mobx.module.js:8,0][static/js/main.f1c66bd9.js:4554,6]

There was a PR (facebookincubator/create-react-app#2485) in create-react-app to remove the module field for production builds, but it was closed due to module builds should only contain es2015 module syntax, otherwise it should be compiled to the target browser.

pkg.module will point to a module that has ES2015 module syntax but otherwise only syntax features that the target environments support.
https://github.com/rollup/rollup/wiki/pkg.module

Hmmm per that article it would seem that the TypeScript compilation target should be changed from es2015 to es5 for the module build. This comment led me to believe the standard practice was to target es2015 features in pkg.module, but the rollup docs seem to contradict that.

@rossipedia was just looking into that as well :). Could someone try whether [email protected] fixes the issue? Unpublished .12 and .13 for now

Moving from 3.1.13 to 3.1.13-fixcra fixed my webpack 2 issue, although I don't use CRA.

@mweststrate I've verified that 3.1.13 breaks production CRA build. I've also verified that changing the target of the module build to es5 from es2015 allows CRA production build to complete successfully.

If I understand https://github.com/webpack/webpack/issues/1979 correctly, esnext field could be used for the ES2015/ESModule target. Just pushed a config change to use ES5 in module

Yeah, per this blog post that would be the way to go. Including untranspiled sources might not be a huge priority at the moment though, as it's a bit too early to tell whether pkg.esnext is going to gain traction.

@mweststrate 3.1.13-fixcra works for me :)

Released 3.1.14. Please let us know if this causes trouble again!

Was this page helpful?
0 / 5 - 0 ratings