Mobx: Multiple MobX instances in your application

[mweststrate]

MobX has some internal global state to be able to track consumers of observables, schedule reactions etc.
For this reason, the rule of thumb is that there should be only one instance of the MobX library in your application. Otherwise, if you have two libraries with their own dependency; reactions created in one library, will _not_ react to observables created with the other library.

Since version 4.2 you will be warned about this:

There are multiple mobx instances active. See https://github.com/mobxjs/mobx/issues/1082 for details.

Solutions to this warning are:

1. If there should be only one mobx instance (libraries should cooperate & react to each other)

_Use peer dependencies_

If you intend the difference libraries you use to react properly to each other. In that case, those libraries should not declare mobx as a dependency, but as peer dependency instead. If you are bundling your libraries independently, make sure to mark mobx as an external dependency. The only place where mobx should be used as a direct dependency is in the "end product", which will provide a single mobx version to all libraries needing it. If you did that properly, the above warning will disappear

Note that it is possible to use _mobx.extras.shareGlobalState()_, this will signal multiple mobx instances to share their global state (if the internal version differences aren't too big). This option mainly exists for legacy reasons; peer dependencies is the neater approach to this problem. shareGlobalState will be removed in 4.0

2. If there are intentionally multiple mobx instances (libraries run in isolation)

_Use mobx.extra.runInIsolation_

In rare cases, you might be building a dynamic system that allows for third party plugins, or you are building such a plugin. In those cases you might be using mobx just for internal purposes inside the plugin, or in the hosting system. However, if you don't intend to use mobx as a communication layer between the plugin and plugin host (which is a very powerful mechanism btw!), you can suppress the above warning by calling mobx.extras.isolateGlobalState(). This signals mobx that it is the intention that multiple mobx instances are active in your application, without tracking each other, and will suppress the above warning.

See #621, #1018, #1066, #1071

3. More extensive trouble shouting guide

See below

[FredyC]

When using mobx.extras.isolateGlobalState() is the call to useStrict() isolated as well? Is seems to me it's not so basically when I want to enable it in my app, but the module running MobX does not care about strict, it will start throwing exceptions.

[mweststrate]

That should be the case. If it isn't, a PR with a test demonstrating the
issue would be appreciated :) (there is a test suite already for testing
multiple loaded mobx instances)

Op zo 30 jul. 2017 om 12:16 schreef Daniel K. [e-mail]:

When using mobx.extras.isolateGlobalState() is the call to useStrict()
isolated as well? Is seems to me it's not so basically when I want to
enable it in my app, but the module running MobX does not care about
strict, it will start throwing exceptions.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx/issues/1082#issuecomment-318891943, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABvGhC7ktUeuEiPSPpWK4yzTi4idU4mnks5sTFf1gaJpZM4OPSmw
.

[aksonov]

@mweststrate RNRF v4 uses mobx internally, but I don't want non-mobx users to require to install mobx (if I make it as peerDependency). Is there any better solution?

[FredyC]

@aksonov Calling mobx.extras.isolateGlobalState() works well, I think it should be called by RNRF by default with option to disable such behavior in case someone would want it shared.

[mweststrate]

I think there is no need for sharing; unless the package explicitly has a
feature that allows passing observables. Isolate is perfect in this case i
think (shouldn't affect or be affected by module deduping)

Op wo 2 aug. 2017 13:19 schreef Daniel K. [e-mail]:

@aksonov https://github.com/aksonov Calling
mobx.extras.isolateGlobalState() works well, I think it should be called
by RNRF by default with option to disable such behavior in case someone
would want it shared.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx/issues/1082#issuecomment-319643789, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABvGhJWA81LRqhi_UzKPV7OBoWkqWopkks5sUFtVgaJpZM4OPSmw
.

[FredyC]

@mweststrate I tried to prepare some example in codesandbox by using regular module import alongside the external umd bundle. Unfortunately, I cannot seem to use mobx-react as external dependency. It's failing with Uncaught TypeError: Cannot use 'in' operator to search for 'default' in undefined when loading from CNDJS.

https://codesandbox.io/s/pQQ2rOxZ2

I am not sure where how I could setup environment to replicate useStatic possible issue. Going with hassle of publishing some testing module seems like overkill.

[ianshea]

We ran into this and discovered we had accidentally imported mobx from two different files in the package.

import {computed} from "mobx";

and in another file from

import {computed} from "mobx/lib/mobx";

Adjusting the second import to just mobx cleared up the issue and resulted in a nice file size savings too. 👍

[mikecann]

I was forwarded here by the console warning:

[mobx] Warning: there are multiple mobx instances active. This might lead to unexpected results. See https://github.com/mobxjs/mobx/issues/1082 for details.

I have a "library" package that has a number of react components that utilize mobx and im trying to share between my apps which also are using mobx.

I have setup my library project.json with peer dependencies like so:

{
    "name": "my-shared-lib",
    "version": "1.0.0",
    "private": true,
    "main": "dist/index.js",
    "types": "dist/index.d.ts",
    "target": "es5",
    "lib": [
        "es6",
        "dom"
    ],
    "jsx": "react",
    "scripts": {
        "link": "npm link",
        "build": "tsc",
        "start": "tsc -w"
    },
    "devDependencies": {
        ...
        "mobx": "^3.2.2",
        "mobx-react": "^4.2.2",
        "mobx-react-router": "^4.0.1",
        "react": "^15.6.1",
        "react-addons-css-transition-group": "^15.6.0",
        "react-bootstrap": "^0.31.2",
        "react-dom": "^15.6.1",
        "react-markdown": "^2.5.0",
        "react-router": "^4.2.0",
        "react-router-dom": "^4.2.2",
        "react-tag-input": "^4.7.2"
    },
    "peerDependencies": {
        "mobx": "^3.2.2",
        "mobx-react": "^4.2.2",
        "mobx-react-router": "^4.0.1",
        "react": "^15.6.1",
        "react-addons-css-transition-group": "^15.6.0",
        "react-bootstrap": "^0.31.2",
        "react-dom": "^15.6.1",
        "react-markdown": "^2.5.0",
        "react-router": "^4.2.0",
        "react-router-dom": "^4.2.2",
        "react-tag-input": "^4.7.2"
    }    
}

and the other projects are consuming using local dependencies: "my-shared-lib": "file:../shared",

which I think is correct but im still getting that warning...

I am using npm link to make things easier for development too so im not sure if thats causing issues... any ideas?

Does anyone have an example of this working?

[johnnyreilly]

Hi @mweststrate,

I'm just spinning up a new project and we're planning to use mobx for our state management. Your project makes it much simpler to do this than Redux (in our team's view) so thankyou! :heart:

We're building up a seed project right now and are experiencing this message:

[mobx] Warning: there are multiple mobx instances active. This might lead to unexpected results. See https://github.com/mobxjs/mobx/issues/1082 for details.

I'm at a loss as to what might be causing this and so I wondered if I could trouble you for pointers?

We're using mobx and mobx-react so we've set up both as peer dependencies; see the relevant part of our package.json:

  "dependencies": {
    "axios": "^0.16.1",
    "core-js": "^2.4.1",
    "history": "^4.6.1",
    "mobx": "^3.2.2",
    "mobx-react": "^4.2.2",
    "react": "^15.6.1",
    "react-dom": "^15.6.1",
    "react-router": "^4.1.1",
    "react-router-dom": "^4.1.1"
  },
  "peerDependencies": {
    "mobx": "^3.2.2",
    "mobx-react": "^4.2.2"
  }

Our imports tend to look like this:

import { inject, observer } from 'mobx-react';
// or
import { observable, action } from 'mobx';

Can you think of anything that might be causing this issue? Or give me any ideas of how I could isolate this? Also, I've seen mention of mobx-extra but I can't find any docs on it. Forgive me if this is a somewhat silly question; I'm a mobx noob.

[mweststrate]

Note that you don't need to set up peer dependencies if you are depending on mobx already. It is an either setup: Either you are creating a library, intended to be used in a _host_ package, and you use peer deps, or you are the _host_ project, and you have mobx / mobx-react as direct dependency and don't need peers. Rule of thumb: if react is a dep, then mobx should be a dep. If react is a peerDep / external, then mobx should be :)

[johnnyreilly]

Sure - that's helpful. Nothing depends on us; we're the host project. So I've dropped the peerDependencies. However the issue still exists.

In case it's relevant, we're using webpack for bundling and experiencing this during watch mode. Could that be triggering this in any way?

Other things that might be relevant: our codebase is TypeScript.

[mikecann]

@john im experiencing something very simmilar (see my post above). I was
going to put together a simple project to demonstrate soon..

[johnnyreilly]

That would be awesome @mikecann - a repro repo speaks a thousand words and all that.

[mikecann]

@johnnyreilly @mweststrate Okay I created a sample repo that demonstrates the issue:
https://github.com/mikecann/mobx-multiple-instance-issue-sample

As mentioned in the readme, im not sure if it has something to do with the post-install build script or something as it only happens if you use yarn not npm.

[johnnyreilly]

Well done! I'm also using yarn in case that's relevant

[mweststrate]

@mikecann not exactly sure what the problem is in your setup, but there sees to be something iffy:

1. mobx is a dep of shared
2. shared is a relative dep of client
3. installing shared in client will cause its deps also to be installed
4. this will probably result in mobx being present in both the node_modules of client and shared
5. module resolution is always relative to the requiring file. Depending on how the 'install' happens (linking or installing) that will resolve mobx from either the client or shared folder (this might be a difference between yarn and nmp)

The current behavior is probably explainable in both cases, but in my general experience linking or relatively installing modules always messes up the dep tree (unrelated to mobx itself, this often caused troubles with webpack loaders, or utility libraries like lodash and such for as well).

Since client is your host package, what the setup should be looking like is at least mobx as dep of client, and peer dep of shared. If you want to be able to compile shared stand alone, that might require mobx also to be a dev dep (for the typings).

The risk of the latter is that if linking the packages; the dev dep is still picked up from 'shared' node modules (because it happens to be there)

One way to solve that issue is to use module aliases in webpack or paths in tsconfig to make sure the module resolves to the correct node_modules.

However, there is one much simpler solution: Put all the 'host' dependencies in the root package.json; where both client and shared can resolve it (node recursively resolves up in the dir structure, regardless where package.json resides). For us that solved the problem in a similar setup where we had closely coupled packages. All other problems where fixable as well by scriptings and such, but still would blow up our bundle regularly by packing two instances of arbitrarily libraries like lodash, mobx and such.

I hope that helps! I didn't try yarn workspaces yet btw, which might be interesting to try out as they promise to solve these kind of problems

[mweststrate]

N.b. to prove point 4, after running yarn install my node_modules look like this:

➜  mobx-multiple-instance-issue-sample git:(master) ✗ ls -x -1 -R | grep mobx: 
./client/node_modules/mobx:
./client/node_modules/my-shared/node_modules/mobx:
./shared/node_modules/mobx:

Npm yielded the same output for me, but that was with npm 3

[johnnyreilly]

Thanks for that @mweststrate - my own setup is rather more vanilla than the setup shared here.

However the problem persists regardless of yarn / npm. I'll try and take the boilerplate TypeScript mobx project and replicate the issue there.

For now we're just ignoring the warning. Should we be worried? Things seem to work.....

[johnnyreilly]

Ps my own project is client only for clarity

[mweststrate]

For now we're just ignoring the warning. Should we be worried? Things seem to work.....

Yes, the different libraries won't track each other observables, so that might mean that mobx-react will react only to half of your observables (the ones created by the instance it resolved it's own mobx dep to)

Besides that the lib will be bundled twice ;-)

[johnnyreilly]

So it does matter :smile:

Interestingly if I look at my yarn.lock file these are the only mentions of mobx:

mobx-react@^4.2.2:
  version "4.3.2"
  resolved "https://registry.yarnpkg.com/mobx-react/-/mobx-react-4.3.2.tgz#1ecbffa5690cc6460db6bb16c0c11034f0b783da"
  dependencies:
    hoist-non-react-statics "^1.2.0"

mobx@^3.2.2:
  version "3.3.0"
  resolved "https://registry.yarnpkg.com/mobx/-/mobx-3.3.0.tgz#1bc1dd7e78547065af04b49bdb7f2098cada47aa"

And in my codebase the imports tend to look like this:

import { inject, observer } from 'mobx-react';
// or
import { observable, action } from 'mobx';

So it seems pretty vanilla from the off...

[mweststrate]

But what does ls -x -1 -R | grep mobx: yield? The important thing is that the module exists only once in your module tree

[johnnyreilly]

JReilly@ICSUKL13943 MINGW64 /c/work/treasury-tools/src/Treasury.App (create-client-seed)
$ ls -x -1 -R | grep mobx:
./node_modules/mobx:

[johnnyreilly]

And if we drop the ::

JReilly@ICSUKL13943 MINGW64 /c/work/treasury-tools/src/Treasury.App (create-client-seed)
$ ls -x -1 -R | grep mobx
mobx
mobx-react
./node_modules/mobx:
./node_modules/mobx/lib:
mobx.d.ts
mobx.js
mobx.js.flow
mobx.min.js
mobx.min.js.map
mobx.module.js
mobx.umd.js
mobx.umd.min.js
mobx.umd.min.js.map
./node_modules/mobx/lib/api:
./node_modules/mobx/lib/core:
./node_modules/mobx/lib/types:
./node_modules/mobx/lib/utils:
./node_modules/mobx-react:

[mweststrate]

ok seems to be unique, so that should normally not produce the warning, unless you are importing mobx wrong somewhere in the code. Make sure all import clauses are like ... from "mobx" without anything else

[mikecann]

@mweststrate Oh that simple solution you offered works!

https://github.com/mikecann/mobx-multiple-instance-issue-sample/tree/the_solution

Thankyou so much, you are a genius 👍 💯 🥇

[johnnyreilly]

Yup all like that (there's only 10 so far)

[mweststrate]

@johnnyreilly ok then best set up a repo indeed

[johnnyreilly]

Sure - will be about 5 mins I think

[mweststrate]

@mikecann note that I advice to do that for any dep that is not unique to a specific subpackage. So also things like React, lodash etc. (you can also add it to a subpackage if it needs a very specific version of lodash, deviating from the others)

[mikecann]

@mweststrate yes indeed, this was what I was trying to do with the shared package. It can now just contain code and the shared npm dependencies can go in the root 😄 I wish I had known about this technique years ago!

[johnnyreilly]

Here's the repro repo: https://github.com/johnnyreilly/mobx-multiple

[johnnyreilly]

If you:

yarn install
yarn start

It will fire up http://localhost:8080 - look at the console and you'll see the error

[johnnyreilly]

Left a compile error in there; just fixed it.

[mweststrate]

@johnnyreilly there is something wrong with your webpack setup, mobx is bundled both into main.js and vendor.js

[mweststrate]

(I did verify that by simply putting a console log and debugger statement on top of node_modules/mobx/lib/mobx.module.js)

[johnnyreilly]

OOOOOOOOOOOOOOOOOOOOOHHHHHHHHHHHHHHHHH I think I forgot the CommonsChunkPlugin. Let me verify and I'll report back. Thanks for your time and apologies in advance if this me being dumb (highly likely)

[johnnyreilly]

Yup - I'm a complete idot. The fix was adding this to my plugins:

        new webpack.optimize.CommonsChunkPlugin({ name: 'vendor', filename: 'vendor.js' }),

So sorry for wasting your time!

[Rikarin]

You cannot use import {} from "mobx/lib/mobx"; with mobx-redux. Use import {} from "mobx";

[Hexxeh]

Just incase anyone runs into the case I did: if you're using jest.mock on a module that imports MobX, you might well see this. You can workaround it by mocking the particular method of the module you need using jest.spyOn().mockImplmentation().

[LukasBombach]

I have a monorepo where one package exposes an observable

package collection

{
  "dependencies": {
    "mobx": "3.3.2",
  },
}

import {observable} from "mobx";

export class Collection {
  @observable items: Array<Item> = [];
}

and another package imports that and uses an observer:

package collection_browser

{
  "dependencies": {
    "@elmc/collection": "1.0.0",
    "mobx-react": "4.3.5",
  },
  "peerDependencies": {
    "mobx": "3.3.2"
  }
}

import {Collection} from '@elmc/collection';

@observer
class CollectionBrowser extends React.Component {

  collection = new Collection({id: 'id', sources: []});

  render() {
    return <ItemList collection={this.collection}/>;
  }

}

This still gives me the error

There are multiple mobx instances active. See https://github.com/mobxjs/mobx/issues/1082 for details.

any ideas?

[mweststrate]

Define mobx as peer dependency in the collection package, and normal dependency in the hosting dependency. You did it the other way around :)

[LukasBombach]

Then I cannot build collection because it misses mobx.

src/Collection.ts(1,26): error TS2307: Cannot find module 'mobx'.
1 import {observable} from "mobx";

[mweststrate]

Then add it as devDependency as well ;-)

Op wo 6 dec. 2017 om 20:15 schreef Lukas Bombach [e-mail]:

Then I cannot build collection because it misses mobx.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx/issues/1082#issuecomment-349744411, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABvGhBrXvSVnPvWBCrg6GAuNIhhZ7_ceks5s9ufNgaJpZM4OPSmw
.

[alexnofoget]

add mobx and mobx react in dependencies in my project. Then setup mobx in peer and dev dependencies in package, after build package in project shows Warning: there are multiple mobx instances active. This might lead to unexpected results

[mweststrate]

Can you doublecheck all mobx imports are correct? (just ffrom "mobx"). Do
you something special in your setup, like linking packages together?
Otherwise, please create small reproduction setup.

Op vr 8 dec. 2017 om 18:18 schreef alexnofoget [e-mail]:

add mobx and mobx react in dependencies in my project. Then setup mobx in
peer and dev dependencies in package, after build package in project shows Warning:
there are multiple mobx instances active. This might lead to unexpected
results

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx/issues/1082#issuecomment-350319557, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABvGhFyL01wSlV8lKQXjid6ddsSBCWq2ks5s-W-AgaJpZM4OPSmw
.

[alexnofoget]

@mweststrate in my package I have package.json like this

"peerDependencies": {
    "mobx": "^3.4.1",
    "mobx-react": "^4.3.5"
  },
  "devDependencies": {
    ................................
    "mobx": "^3.4.1",
    "mobx-react": "^4.3.5"
  },
  "dependencies": {}

In project

  "dependencies": {
    "mobx": "^3.4.1",
    "mobx-react": "^4.3.5",
    ............
  }

webpack confing:

var path = require('path');
module.exports = {
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, 'build'),
    filename: 'index.js',
    libraryTarget: 'umd' 
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        include: path.resolve(__dirname, 'src'),
        exclude: /(node_modules|bower_components|build)/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ["env", "react"],
            plugins: [
              "transform-decorators-legacy",
              "transform-function-bind",
              "transform-object-rest-spread",
              "transform-class-properties",
              "transform-react-jsx-source"
            ]
          }
        }
      }
    ]
  },
  externals: [
    'react', 
    'mobx',
    'mobx-react'
  ]
};

[mweststrate]

Looks correct to me, assuming the webpack config describes the package. Best create a small repository showing the problem to be able to say anything more about it, many factors have impact on this.

[nareshbhatia]

@mweststrate and @alexnofoget - I was running into similar issues and finally set up two sample repos to straighten this out. Michel, your suggestion to "add it as devDependency as well" was the key. Please have a look at my repos and tell me if I got it right:

1. multiple-mobx-library is a library that uses MobX. It exposes a MobX-enabled React component and also a MobX store.
2. multiple-mobx-client is the "end-product" that depends on the above library, but also uses MobX internally. In addition, I made it to use the store exposed by the library to make sure they are both accessing the same instance!

Feedback welcome!

[jarecsni]

It is a rather annoying issue which is hard to track down. I just started to have it and have no idea how to go about it. In my humble opinion, this should be done better by mobx, as it's apparently quite easy to end up being in this situation without doing anything blatantly wrong. @mweststrate is it not possible to find a less fragile way? (Sorry - being frustrated trying to get a unit test work for 2 hours now.. :))

(My project is an end user app which is using Mobx and MST. I only import it in the recommended way, from 'mobx'. And this used to work until recently. Mobx is defined as a normal dependency alongside React. It's an expo react native project. Not sure what other detail may be relevant?)

[jarecsni]

Just want to add that in my case it if I call a store.setSomeExcitingVariable() then the test fails as it never returns from that call, and also the app crashes. If I omit calling the store method, then things are 'fine'. Thought it may be relevant.

[jarecsni]

Mobx warning is a possible red herring in my case (at least I'm having unrelated issues too) - will write a follow-up when I manage to get to the bottom of my issue!

[jarecsni]

Unrelated to my other issues it turned out that this warning about multiple mobx's can happen if you inadvertently create a store multiple times (I was having a circular dep kind of situation where one module that imported a store also imported a module that in turn imported my store. (The store factory logic was flawed, so all working fine now, but thought I leave this comment if someone is having a similar problem.)

[mweststrate]

To summarize a bit and give an overview of some trouble shooting pointers

1. what is the problem?

The problem is that MobX is being loaded twice into your application. This is sad for two reasons:

1. it blows up your bundle size unnecessarily
2. MobX internall keeps state of the relations between observers and observables. And observer created by one instance of the package will not be able to track observables created by another instance of the mobx package.

2. The bad workaround: shareGlobalState()

There is a work around for this, namely calling mobx.extras.shareGlobalState() on both packages. This is however unrecommended, as it does not address the original problem; mobx being loaded twice.

_But: it breaks package isolation_. When shareGlobalState is used, it is important that all mobx versions use (almost) the same version, as the internal api's might change over time. This feature is disabled by default and unrecommended, as not doing this allows packages to package mobx internally, and listen to only their own observables, without interference with the hosting application. In other words; package isolation is a good thing and should be kept as so.

(Remember building webpages with 5 different jquery versions loaded in your global space and your awesome wordpress breaking because it get's the wrong version? That is what we are trying to prevent).

For better work arounds, read on to find what is appropriate to your situation

3. Solution guides

So, why are multiple mobx instances being used in your application.

1. Don't import from "mobx/lib/something"

The nr. 1. reason is using wrong imports. There is a bug in Typescript, affecting VS Code (and other editors) to autocomplete on the wrong path. Issue. This should be solved in TS 2.7, but in the mean time, check if you see any import of the form from "mobx/lib/xxxxx"; and replace it with just from "mobx";.

_background_: The problem is that mobx exposes UMD builds, ES modules and common js modules from the same package (as is appropiate). Modern bundlers like webpack will rightfully prefer loading ES modules. But import statements like the above point directly into the commonjs module, cause webpack to bundle both the es module and the common js version of Mobx.

If this is the cause of your problems, it is easily fixed :)

2. Don't depend on mobx directly in packages. use dev- and peer dependencies instead

If you have a package that is supposed to be used inside another app, don't use mobx as dependency! For example if you create package mypackage with an observer based component that is supposed to react to the observables created by that app, don't use mobx (nor mobx-react) as dependency, but use it as peerDependency. Like you would do with for example React. This makes the host application responsible for providing MobX, and ensures there is one mobx package only. It is important that if you bundle your package, that mobx and affiliate packages are marked as "external".

However, having 'mobx' just as peer dependency in your package can make developing the package itself cumbersome in terms of testing or typing. So for that reason you should add mobx and such as devDependency as well. (But remember: not as normal dependency because that would cause installing your package in another project mobx to be installed another time)

mypackage/package.json

"peerDependencies": {
    "mobx": "^3.4.1",
    "mobx-react": "^4.3.5"
  },
  "devDependencies": {
    "mobx": "^3.4.1",
    "mobx-react": "^4.3.5"
  },
  "dependencies": {}

app/package.json

  "dependencies": {
    "mobx": "^3.4.1",
    "mobx-react": "^4.3.5",
    "mypackage": "0.0.0"
  }

3. Beware of linking packages

Dev dependency are tricky however when linking packages. Given the following

     node_modules
         mypackage -------> (symlink) ../../mypackage
         mobx

mypackage
     somefile.js
     node_modules
            mobx

This will cause app to use mobx from app/node_modules/mobx as it should. mypackage/somefile.js should resolve mobx to that package as well (it is a peer dependency after all). However, it will resolve mobx to mypackage/node_modules/mobx instead, as require calls in commonjs are relative and will prefer the closest module for importing. And if it wasn't there, it wouldn't be able to resolve mobx at all. Since the node_modules folder of app is nowhere in the path of mypackage (symlink doesn't change that, and require will only search up-ward, but not into sibling directories!)

This is a problem that will be addressed in upcoming NPM releases (many packages suffer from this).

These are some workarounds to this problem that I have used successfully in the past

1. app and mypackage are both maintained in the same repository, use yarn workspaces. They are really great and solve this problem consistently (by pulling up- and sharing the node_modules folder of both packages).
2. Symlink mobx in mypackage back to app/node_modules/mobx so that there is only one mobx package on disk. This works, but easily becomes a mess with many packages and peer depencies.
3. If you are using webpack, you can force mobx to be always resolved to app/node_modules/mobx, by using webpack aliases: alias: { mobx: path.resolve(__dirname, 'node_modules/mobx') }). Most other bundlers / build tools have options for this as well. It might be that you need to do the same for your Jest setup for example: "jest" : { "moduleNameMapper": "mobx": "<rootDir>/node_modules/mobx" }
   
   
   
   1. An untested work around is to enable some magic flag on node, which makes it treat symlinks differently blog . I have no idea how well that works.
   
   

[nareshbhatia]

@mweststrate, thanks for this awesome summary. A couple of quick comments:

• I have read that peer dependencies should be lenient (e.g. "mobx": "^3.x"), not as tight as "mobx": "^3.4.1".
• Another workaround is to use npm pack to pack the library locally and then installing it in the dependent app. For example:

In mypackage

npm pack

This produces mypackage-0.1.0.tgz

In app

npm install --save ../mypackage/mypackage-0.1.0.tgz

Not very pleasant, still a workaround!

[danieldunderfelt]

@ianshea Dang, WebStorm uses mobx/lib/mobx if you let it auto-add the import. Very annoying. Thanks for mentioning this, it helped me! I'll keep my eyes open if it decides to do this again.

[mweststrate]

@danieldunderfelt it is actually a bug in TS-server afaik, so will solved in newer TS versions for any IDE

[breakds]

If the shared library itself is a local module (yarn add file:../../../my-shared-module), the shared module itself may have node_modules/mobx. Even if all dependencies such as mobx and mobx-react are marked as peer and dev dependencies, the node_module/mobx will be included with that yarn add.

Therefore in my main project there will be 2 mobx:

$ ls -x -1 -R | grep mobx:
./node_modules/mobx
./node_modules/my-shared-module/node_modules/mobx

The only (hacky) solution I found is to manually remove the node_modules directory in the shared module directory after a build ...

[danieldunderfelt]

@mweststrate oh, good to know! WebStorm does the same for styled-components 🙄 Thanks!

[alexnofoget]

I solved this problem. I used my own module through npm link localy. Therefore creating two instances of mobx. When I moved to remote repo my module, I got one instance

[mweststrate]

Sorry, that is way too little information to be of any help. Did you go
through the two extensive posts first?

Op wo 28 feb. 2018 om 16:51 schreef mallikvarma [e-mail]:

I have the same problem where console throw a warning about the muiltiple
instances of mobx being used.
I am working on a simple reactjs single page application.
Package.json looks like below

"dependencies": {
"babel-polyfill": "6.23.0",
"mobx": "^3.5.1",
"mobx-react": "^4.4.2",
"react": "15.4.2",
"react-dom": "15.4.2"
}

and the component

import { observable, action } from "mobx";
import { observer } from "mobx-react";
@Observer https://github.com/observer
export class CreateSharingGroup extends React.Component{
constructor(params){
super(params);
this.state = {show:false};
};

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx/issues/1082#issuecomment-369279980, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABvGhN41pn1Gu1NoZJrtpk0Aiw8utav9ks5tZXPUgaJpZM4OPSmw
.

[mallikvarma]

Yes I have gone through above 2 examples and followed the same. To be honest its not easy for the developer to get mobx-react version 4 working. Annoyed, I have moved to 3.0 and that resolved the issue.

[mweststrate]

mobx or mobx-react?

Op do 1 mrt. 2018 om 16:13 schreef mallikvarma [e-mail]:

Yes I have gone through above 2 examples and followed the same. To be
honest its not easy for the developer to get mobx-react version 4 working.
Annoyed, I have moved to 3.0 and that resolved the issue.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx/issues/1082#issuecomment-369622970, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABvGhEOyHYv8tNgUucTgdIFNrQEyGfI9ks5taBATgaJpZM4OPSmw
.

[mallikvarma]

Sorry, I moved to mobx 3.0.0 and mobx-react is 4.4.2

[mweststrate]

which mobx version were you trying?

Op do 1 mrt. 2018 om 16:45 schreef mallikvarma [e-mail]:

Sorry, I moved to mobx 3.0.0 and mobx-react is 4.4.2

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx/issues/1082#issuecomment-369633694, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABvGhLBxLCG0x73eNUwtAeiaAGlEwiRPks5taBeogaJpZM4OPSmw
.

[mallikvarma]

I was using mobx 3.6.1

[pedsmoreira]

In case someone encounters the same error:

I have a package in one project and a app created with create-react-app on another and I wanted to use my package on my create-react-app demo. After struggling for a while I found the response in this issue and I wanted to share how to make the linking work on create-react-app + react-app-rewired:

config-overrides.js

const path = require('path');
const rewireMobX = require('react-app-rewire-mobx');

module.exports = function override(config, env) {
  config = rewireMobX(config, env);
  config.resolve.alias = {
    mobx: path.resolve(__dirname, 'node_modules/mobx')
  };
  return config;
};

[nrigaudiere]

Hi everyone,

I am currently migrating from PHP/Jquery to ReactJS/MobX and I have one MobX store per PhP page as I'm currently migrating.

So I was having this issue but it was just set as a warning but I've migrated to [email protected] and now it is shown as an Error :/

mobx.module.js:2625 Uncaught Error: [mobx] There are multiple mobx instances active. This might lead to unexpected results. See https://github.com/mobxjs/mobx/issues/1082 for details.
    at invariant (mobx.module.js:2625)
    at fail$1 (mobx.module.js:2620)
    at mobx.module.js:2850

Would someone have an idea on how to handle this?

Thank you very much!

[mweststrate]

Please read the pointers in this thread.

Op wo 14 mrt. 2018 om 12:05 schreef Nicolas Rigaudiere <
[email protected]>:

Hi everyone,

I am currently migrating from PHP/Jquery to ReactJS/MobX and I have one
MobX store per PhP page as I'm currently migrating.

So I was having this issue but it was just set as a warning but I've
migrated to [email protected] and now it is shown as an Error :/

Would someone have an idea on how to handle this?

Thank you very much!

mobx.module.js:2625 Uncaught Error: [mobx] There are multiple mobx instances active. This might lead to unexpected results. See https://github.com/mobxjs/mobx/issues/1082 for details.
at invariant (mobx.module.js:2625)
at fail$1 (mobx.module.js:2620)
at mobx.module.js:2850

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx/issues/1082#issuecomment-372983594, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABvGhCk-dHYeFQfilSra5_KSH0oLvPtHks5tePl_gaJpZM4OPSmw
.

[ddbradshaw]

FWIW - After updating my version on mobx-state-tree, I started receiving this error. I needed to then also update my version of mobx such that the version of mobx was higher than the stated version of the peer dependency in mobx-state-tree, otherwise webpack includes two different versions of mobx in the bundle and this exception is thrown.

[felixzxk]

my react-native project, downgrade mobx to 3.6.2, mobx-react to 4.4.2

[abelkbil]

Dashboard.test.ts

import DashboardStore from '../Stores/DashboardStore';

describe('DashboardStore', () => {
    let dashboardStore;
    beforeEach(() => {
        dashboardStore = DashboardStore;
    });
    // tslint:disable-next-line:no-console
    console.log(dashboardStore);
});

 FAIL  src\__tests__\DashboardStore.test.ts
  ? Test suite failed to run

    TypeError: Cannot create property '__mobxInstanceCount' on boolean 'true'

      at Object.<anonymous> (node_modules/mobx/lib/mobx.js:2620:38)
      at Object.<anonymous> (src/Stores/DashboardStore.ts:9:14)
      at Object.<anonymous> (src/__tests__/DashboardStore.test.ts:3:24)

Test Suites: 1 failed, 1 total

mobx.js:2620 mentions about global multiple instance.

DashboardStore.ts

1 import { observable, action } from 'mobx';
2 import * as _ from 'lodash';
3 import agent from '../agent';
4 import { DragableItemModel, WidgetModel } from '../Model/Widget';
5 import widgetsListStore from './WidgetsListStore';
6 import timeSettingsStore from './TimeSetingsStore';
7 import { LayoutItem } from '../Model/LayoutItem';
8 import { MOMDatasource } from '../Services/MOMService';
9 import { DashboardModel } from '../Model/Dashboard';
10 import { DashboardService } from '../Services/DashboardService';
11 export class DashboardStore  {

"jest": {
    "collectCoverageFrom": [
      "src/**/*.{js,jsx,ts,tsx}"
    ],
    "setupFiles": [
      "<rootDir>/config/polyfills.js"
    ],
    "testMatch": [
      "<rootDir>/src/**/__tests__/**/*.ts?(x)",
      "<rootDir>/src/**/?(*.)(spec|test).ts?(x)"
    ],
    "testEnvironment": "node",
    "testURL": "http://localhost",
    "transform": {
      "^.+\\.tsx?$": "<rootDir>/config/jest/typescriptTransform.js",
      "^.+\\.css$": "<rootDir>/config/jest/cssTransform.js",
      "^(?!.*\\.(js|jsx|mjs|css|json)$)": "<rootDir>/config/jest/fileTransform.js"
    },
    "transformIgnorePatterns": [
      "[/\\\\]node_modules[/\\\\].+\\.(js|jsx|mjs|ts|tsx)$"
    ],
    "moduleNameMapper": {
      "^react-native$": "react-native-web"
    },
    "moduleFileExtensions": [
      "mjs",
      "web.ts",
      "ts",
      "web.tsx",
      "tsx",
      "web.js",
      "js",
      "web.jsx",
      "jsx",
      "json",
      "node"
    ],
    "globals": {
      "ts-jest": {
        "tsConfigFile": "tsconfig.test.json"
      },
      "window": true
    }
  }

My request is provide some hind on how to unit test a component and store.
Thanks you.

[n06rin]

After upgrade webpack to 4 version, I'm stucked with this problem.
At webpack 3 we use CommonsChunkPlugin, but now it is deprecated.

Now I'm try configure splitChunksPlugin:

{
 module: {},
 optimization: {
    splitChunks: {
      cacheGroups: {
        commons: {
          test: /[\\/]node_modules[\\/]/,
          name: "vendor",
          chunks: "all"
        }
      }
    }
  }
}

But anyway I'm see that error.
I'm try manually set alias as described here

alias: { mobx: path.resolve(__dirname, 'node_modules/mobx') })

But that didn't help.

And in my project, I have separate version of mobx, but only for storybook/react. And if I remove them, that didn't help.

ls -x -1 -R | grep mobx:
./node_modules/mobx:

[mweststrate]

Locking this conversation as adding more examples only makes this thread more uncomprehensible.

Please read those comments _carefully_, a few times.

• https://github.com/mobxjs/mobx/issues/1082#issue-240875563
• https://github.com/mobxjs/mobx/issues/1082#issuecomment-352409804

And only then open an issue, including a small reproduction.

[mweststrate]

In MobX 4.4 / 5.1 the behavior has changed and sharing is now the default. Please note that nonetheless one should make sure a module is included only once, but this is now considered the responsibility of the consumer