Dmitry

@egorguscha there is another [supported alias](https://github.com/effector/effector/blob/master/src/babel/babel-plugin.js#L472) for `.createDomain`: `.domain`, which leads to this issue

I agree that custom errors should force error on proper field, as there are a lot of obvious cases, in which we could select another field to highlight. This is...

Effector has `compat` builds for using with antique targets without compilation. It indeed has IE11 Chrome 47 support ```js import {createStore} from 'effector/compat' import {useStore} from 'effector-react/compat' ``` https://unpkg.com/effector/compat.js [Compatibility...

Agree, will be grateful for help

This mean that babel-plugin is working too late: it’s always better to run it on unprocessed sources, as it really, really need unambiguous matching between runtime and lines of source...

Btw, very nice trick, I like it 👍👍

Yes, in general the order is always matter in babelrc As for our use case, if one of the plugins add some code, then at the time of effector’s plugin...

Would be great to see that 👍 How it’s supposed to use? I mean, I have a project with 5 files with models, which steps should I do?

In last year I wrote snippet for state reloading, with a feature for clearing old units it will looks like that: **@effector/hmr/index.js** ```ts import {root} from 'effector-root' import {clearNode} from...

Probably, we'll need to add such import to every module, but I think it's easier to do programmatically than adding a function call for every unit