🚀 Proposal: MobX 6: 🧨drop decorators,😱unify ES5 and proxy implementations, 💪smaller bundle #2325

mweststrate · 2020-04-01T20:17:13Z

spion · 2020-04-01T20:38:11Z

You probably already know this 😀 but here is my strong vote against removing decorators. I frankly don't care what TC39 think, decorators are here to stay. I'm not removing them from any codebase and I will strongly advocate against any removal from any library as well.

IMO its time to stand our ground.

Bnaya · 2020-04-01T22:01:34Z

Quick thought:
What about adding decorators with external package to mobx core?
"mobx-decorators"
Do we expose the needed low-level primitives?

urugator · 2020-04-01T22:03:21Z

observable(1) cannot be <T>(value: T, options?) => T (as it must return some box), correct?
How does this work with class field value: int = observable(1)?

I worry that this data/metadata duality will backfire eventually. If I remember correctly we had something like this in Mobx2.

~~Had an idea like:~~
EDIT: nevermind bad idea...

xaviergonz · 2020-04-01T22:08:52Z

🧨 1. Become compatible with modern ES standards

Personally I also hate what TC39 is doing to decorators, and maybe it is one of those things that should be left to transpilers. Maybe there could be a mobx-decorators v7 package for those that want to keep using with them? (and also could make adoption easier).

😱 2. Support proxy and non-proxy in the same version

Sounds awesome.

💪 3. Smaller bundle

To further decrease the build, I'd personally love to drop some features like spy, observe, intercept, etc. And probably a lot of our low-level hooks can be set up better as well, as proposed by @urugator.

As long as there are alternatives it should be ok (mobx-keystone for example relies on both observer, intercept and then some more). But the more changes there are, the more likely current mobx libs will become incompatible and stop adoption.

🍿API changes

autoInitializeObservables will reflect on the instance, and automatically apply observable, computed and action in case your class is simple

When is a class considered simple? When there are no fields with mobx "decorators"?
If so, it might be confusing to have a "simple" class, then add an action and see how the whole class becomes something totally different.

observable and extendObservable does currently convert methods to observable.ref's instead of actions by default.

I think 99% of the time you'd want functions to become actions (and actually I didn't even know this observable.ref was the case), so as long as this is explained on some release notes it should be ok.
In the worst case there could be a global flag like "versionCompatibility": 5 or similar that actually makes it work as usual for those migrating from an older version and that prints in the console a warning when a function is passed to observer so you can eventually fix it and remove the flag.

kubk · 2020-04-01T22:46:18Z

To further decrease the build, I'd personally love to drop some features like spy, observe, intercept, etc.

mobx-logger depends on spy as well as mobx-remotedev (Redux devtools for Mobx). Is there another way to listen to observable mutations in Mobx?

danielkcz · 2020-04-02T05:01:46Z

You probably already know this 😀 but here is my strong vote against removing decorators. I frankly don't care what TC39 think, decorators are here to stay. I'm not removing them from any codebase and I will strongly advocate against any removal from any library as well.

IMO its time to stand our ground.

@spion Frankly, that is just a rant. Michel wrote the pros of removing decorators. If you want to "stand ground" and "strongly advocate", then please make constructive counter-arguments instead of just "I like them".

Personally, I am on the other side of this war and I never liked decorators. This fresh new look definitely makes sense to me. However, if there is some possibility to keep decorators support in the external package as it was suggested, then it's probably something we should do. If people feel the necessity to wear a foot gun, it's their choice. Besides, it would be suddenly more apparent where that decorator magic is coming from and that it's something optional.

mweststrate · 2020-04-02T06:52:27Z

No, being serious here 🙈. Missed opportunity though! Op do 2 apr. 2020 06:50 schreef Nir Weber <notifications@github.com>:

…

April fools @mweststrate <https://github.com/mweststrate> ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2325 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBGYSQOTJNWFY5ZPUYLRKQRTHANCNFSM4LZQ2B5Q> .

mweststrate · 2020-04-02T08:28:56Z

I worry that this data/metadata duality will backfire eventually. If I remember correctly we had something like this in Mobx2.

Yeah, I think that is the part I like the least as well. Maybe we should introduce a separate 'marker' to for observable properties, e.g. field = tracked(value), and use observable only for instantiating collections (mostly relevant when not using classes). But not sure whether we should have an alternative for computed as well, and what would be a good name.

benjamingr · 2020-04-02T08:51:43Z

I like decorators but I totally understand this direction. There are a few reasons for this, let me try and make Gorgi's case @FredyC :

Decorators are explicit, I get to say exactly what is reactive, no fields are reactive implicitly.
Decorators are declarative, it feels like another meta-property of the type (like private, or readonly) which addresses a concern of the field (reactivity).
Decorators are the way this is done in other systems (like Angular) and languages (like UI systems in C# or Python)
Decorators have been the "mostly standard MobX way" for a while and removing them is 5 years of breakage.

Also, removing something so widely used because the spec committee can't proceed always leaves a bad taste in my mouth. Even as I acknowledge they are all acting in good faith and that decorators are a hard problem for engines because of the reasons outlined in the proposal (I've been following the trapping decorators discussions).

benjamingr · 2020-04-02T08:59:46Z

Some API bikeshedding:

Decorators

class Doubler {
  @observable value = 1

  @computed get double() {
    return this.field * 2
  }

  @action increment() {
    this.value++
  }
}

Michel's original:

class Doubler {
  value = 1

  get double() {
    return this.field * 2
  }

  increment() {
    this.value++
  }

  constructor() {
    autoInitializeObservables(this)
  }
}

Subclass:

class Doubler extends ObservableObject {
  value = 1

  get double() {
    return this.field * 2
  }

  increment() {
    this.value++
  }
}

Can be interesting, but is not very good in terms of coupling. Or with a class wrapper:

const Doubler = wrapObservable(class Doubler {
  value = 1

  get double() {
    return this.field * 2
  }

  increment() {
    this.value++
  }
});

danielkcz · 2020-04-02T09:55:54Z

Decorators have been the "mostly standard MobX way" for a while and removing them is 5 years of breakage.

Don't forget there will be a codemod to make most of the hard work for you, so this isn't really a valid argument. Besides, nobody is forced to upgrade to the next major. It probably depends if we will be able to maintain v4 & v5 or abandon those. And if we separate package will exist for decorators then it might be fairly non-braking change.

Btw, @mweststrate Just realized, why MobX 7? Do we need to skip V6 for some reason? 🤓

mweststrate · 2020-04-02T10:01:31Z

Doh, I can't count. Subclassing doesn't work, as the fields are not visible to the subclass when it runs its constructor. Wrapping is probably a bit scary for many people, but more importantly it is troublesome in TypeScript, as generic arguments aren't nicely preserved that way, and with circular module dependencies, as const expressions are not hoisted the same way as classes IIRC (that is an recurring issue in MST).

…

On Thu, Apr 2, 2020 at 10:56 AM Daniel K. ***@***.***> wrote: - Decorators have been the "mostly standard MobX way" for a while and removing them is 5 years of breakage. Don't forget there will be a codemod to make most of the hard work for you, so this isn't really a valid argument. Besides, nobody is forced to upgrade to the next major. It probably depends if we will be able to maintain v4 & v5 or abandon those. And if we separate package will exist for decorators then it might be fairly non-braking change. Btw, @mweststrate <https://github.com/mweststrate> Just realized, why MobX 7? Do we need to skip V6 for some reason? 🤓 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2325 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBE6PWAMDR7QF4WVJFDRKROL7ANCNFSM4LZQ2B5Q> .

benjamingr · 2020-04-02T10:08:54Z

@FredyC hey, I would prefer it if we avoided terms like "isn't really a valid argument" when talking about each other's points.

I think having a common and standard way to do something in a library (decorators) is definitely a consideration and API breakage is a big concern - even with a codemod. I think removing decorators is unfortunately the way forward - but breaking so much code for so many users definitely pains me.

@mweststrate subclassing is also not very ergonomic and mixes concerns here IMO.

I'm not sure I understand the wrapping issue in TypeScript but I know there are challenges involving it. Wrapping doesn't actually have to change the type similarly to initializeObservables:

class Doubler {
   ...
}
initializeObservables(Doubler); // vs in the constructor

Or even decorate the type in a non-mutating way:

const ReactiveDoubler = initializeObservables(Doubler); // vs in the constructor

Wouldn't it make more sense to initializeObservables on the type and not on the instance? Is there any case I'd want to conditionally make an instance reactive but not have several types?

mweststrate · 2020-04-02T10:30:51Z

@benjamingr yeah that is exactly what decorate does so far. The problem is that initializeObservables won't see the fields if invoked on the type, field x = y is semantically equivalent to calling defineProperty(this, 'x', { value: y }) in the constructor, so the field does never exist on the type.

So even if you don't know the fields, but you do specify them on the type, you can't decorate the type to trap the assignment, because the new property will simply hide it. I think it is still a weird decisions to standardize [[define]] over [[set]] semantics, which has rarely any merits, and deviates totally from what TS and babel were doing. But that is how it is.....

spion · 2020-04-02T10:43:57Z

@FredyC It is not a rant, it's a constructive comment. Decorators are widely used throughout the community, with large projects such as Angular, NestJS and MobX taking advantage of them. Thousands of projects depend on them. For TC39 to block their standardization process strikes me as extremely irresponsible, and the arguments for doing so are severely under-elaborated (a vague 3-pager does not an elaboration make - try harder TC39).

The advantages that @mweststrate mentioned are largely the fault of this lackluster standardization which means the argument is cyclic: it ultimately comes down to "we're not supporting decorators because decorators are not well supported". Language features that aren't yet standardized are never well supported, the argument can be used to justify not adopting any new language feature. So if TC39 "paves cowpaths" and everyone adopted this way of thinking, the language would stop evolving.

(Clearly, this is not a new feature so there is some merit to the "not likely to be supported" argument implying its a good idea to give up on them. I just wanted to bring to the table that the other approach - standing our ground - might be good too)

For those of us who do care about decorators, what are our options? Our only hope is to stand our ground, keep using them and keep advocating their standardization. Even if TC39 doesn't standardize them, development within TypeScript might continue, addressing the remaining gaps WRT reflection and types.

If you don't care about decorators, please stay out of it. They have always been optional in MobX and will continue to be optional - no one is forcing you to use them. If you care about a smaller bundle, they can be offloaded to a side module (but I maintain they should still have a first-class place in the documentation)

benjamingr · 2020-04-02T10:45:10Z

@mweststrate is there anything stopping us from trapping construct and intercepting those fields then or setting a proxy?

Such an initializeObservables wouldn't do anything until an object is constructed and then return a proxy (or decorate) when the constructor is called.

That is:

Someone calls makeReactive/nitializeObservable and passes it a class
That someone gets a new class back that is a proxy over the old class. (vs. a proxy for the instance by intercepting construct)
When that class is constructed - we intercept the fields at the end of the constructor (after invoking it) and make it reactive. (Or with proxies we just return a proxy since we don't need to do work-per-field).

That way the fact the field is not a part of the type doesn't really matter - since while it looks like we are decorating the prototype/class we are actually decorating the instance and only "decorating" the construct on the type.

trusktr · 2020-09-08T08:13:50Z

Perhaps if the API were as follows, the construction performance could be improved at a slight cost in DX:

class Foo {
  @observable foo = 123

  constructor() {
    makeObservable(this, Foo)
  }
}

class Bar extends Foo {
  @observable bar = 456

  constructor() {
    super()
    makeObservable(this, Bar)
  }
}

class Baz extends Bar {
  @observable baz = 'hello'

  constructor() {
    super()
    makeObservable(this, Baz)
  }
}

const baz = new Baz

autorun(() => {
  console.log(baz.foo, baz.bar, baz.baz)
})

It would be faster because the decorators could map constructors to keys (f.e. Ctor[symbol].push(propName)), and the
makeObservable calls would not have to traverse the prototype and not have to check own props to see if they exist.

olee · 2020-09-08T18:05:14Z

@trusktr I think this is an interesting idea and one should not forget performance in the whole matter.
Are there any performance comparisons yet between mobx 4/5/6?

trusktr · 2020-09-09T19:57:12Z

I haven't made any comparisons, but if we have 1000 instances of the above Baz, then in the MobX 5 version there would have only been 3 decorate calls (O(1)), while in the MobX 6 version there will be 3000 makeObservable calls (O(n), previous optimization idea aside).

Not sure if it is worth it, but perhaps having both is an option: makeObservable(this) is more concise and fine for most cases, while makeObservable(this, Baz) could be an optional way to call it that entirely short-circuits the prototype traversal and the prop checking (still doesn't eliminate the 3000 calls).

urugator · 2020-09-10T12:35:03Z

then in the MobX 5 version there would have only been 3 decorate calls (O(1))

Even in Mobx4/5 there is a logic similar to makeObservable that runs per instance, it just happens lazily when you access a decorated field for the first time.

mobx/src/v5/utils/decorators.ts

Line 43 in 9a4d67f

initializeInstance(this)

Moving the call to constructor actually makes it a lot less complicated.
I don't say a one is necessarily faster than other, just saying it's not simply 3 vs 3000 calls.

mweststrate · 2020-09-10T19:44:47Z

We have benchmark tests for creating 100.000 class instances. The results are as follow:

version	test	creation	updates
6	typescript + decorators	7616	11319
6	typescript + makeObservable	9029	13025
6	babel + decorators	7801	11762
6	babel + makeObservable	9266	13490
5	typescript + decorators	2525	5140
5	babel + decorators	2755	5426
4	typescript + decorators	2766	7416
4	babel + decorators	2813	7470

So things have became a bit slower indeed. I can imagine there are some optimisation opportunities here and there still. But the change isn't in a different order of magnitude, and so far object creations or updates being to slow have never been reported as an issue with mobx (IIRC), so I'm not too worried for now; it is quite likely you hit other bottlenecks first when dealing with 100k object, so without real life scenarios in which MobX object interactions prove to be the bottleneck, I'm not worried at this moment.

I suspect however that the primary reason for the slow-down is the babel / TS config change to use [define] instead of [set] to initialise fields, but I didn't actually measure it as no benchmarking tool seems allow playing quickly with babel options. But see this link for why that might matter a lot

olee · 2020-09-10T22:51:56Z

Ouch - that link you shared really shows how bad this change regarding define semantics for class fields is.
Would it be possible to run a v6 benchmark without the transpilation to define semantics enabled so it can be exluded from the comparison?

mweststrate · 2020-09-11T08:13:39Z

honestly I would worry too much about such microbenchmark, they give really little relevant information. First of all, engines might still be catching up with their optimizations and a few months from now things might look entirely different. Secondly object creating and field assignments is probably like 0.01% of the work your app is doing and unlikely to be the bottleneck of your application, and not making a difference in user experience if you make it either 3 times slower or faster.

…

On Thu, Sep 10, 2020 at 11:52 PM Björn Zeutzheim ***@***.***> wrote: Ouch - that link you shared really shows how bad this change regarding define semantics for class fields is. Would it be possible to run a v6 benchmark without the transpilation to define semantics enabled so it can be exluded from the comparison? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2325 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBGY7HYADII4UYU77CLSFFKBZANCNFSM4LZQ2B5Q> .

bb · 2020-09-11T12:38:56Z

Edit: Fixed in mobx@6.0.0-rc.8

Not sure if this worth a separate issue... I decided to post it here as it's something new introduced with MobX 6:

When upgrading from TypeScript 3.9.7 to TypeScript 4.0.2 I'm receiving an error when providing a second argument to makeAutoObservable. I assume something was made stricter in newer TS version and MobX needs to catch up (but I'm not really sure).

Here's a code sandbox, relevant section highlighted: https://codesandbox.io/s/ecstatic-lake-s93v4?file=/src/App.tsx:351-480

The Code Sandbox is currently fine as it is using TypeScript version 3.9.7 which can be seen in the lower right corner. It seems to me that I cannot change the TS version inside CodeSandbox.

However, when downloading that via Menu File→Export as Zip, doing npm install and then running react-scripts build I get the following error:

TypeScript error in /Users/bb/Downloads/s93v4/src/App.tsx(16,30):
Argument of type '{ exampleShallowMap: Annotation & PropertyDecorator; exampleShallowArray: Annotation & PropertyDecorator; }' is not assignable to parameter of type 'Partial<Record<keyof this, AnnotationMapEntry>>'.  TS2345

    14 |
    15 |   constructor() {
  > 16 |     makeAutoObservable(this, {
       |                              ^
    17 |       exampleShallowMap: observable.shallow,
    18 |       exampleShallowArray: observable.shallow
    19 |     });

The same error is also marked in latest VS Code (August Update, which is using TS 4.0.2) but was not yet marked in the July Update (which is using TypeScript 3.9.7 like the Code Sandbox).

olee · 2020-09-13T17:52:08Z

Secondly object creating and field assignments is
probably like 0.01% of the work your app is doing and unlikely to be the
bottleneck of your application

I'm not sure about that - especially when having something like a virtual repeat which loads pages of entities, even small delays could cause the view to lag.
However I guess you are right - more often deserialization etc. takes up waay more time than something like class instantiation (though I would like to test this out sometime)

stephy · 2020-09-16T02:25:25Z

Honestly... I am sad to see the decorators go. I am big fan of their simplicity and clarity. I am happy to see that there will be a work around to be able to continue to use them. However, I am thinking it will be quick to adapt to the new syntax

I am guessing this choice was probably a good call. Maybe now without decorators I am hopeful I will be able to convey to people how amazing Mobx is and at least I won't hear the decorators excuse anymore. I have never seen an "@" sign scare so many people.

olee · 2020-09-17T10:35:24Z

@mweststrate if you have some time, could you give us an update on what is left to do before we can maybe get a mobx v6 beta and when we (roughly) might expect a v6 release?

bb · 2020-09-17T11:55:52Z

@olee -- I don't know about the release schedule but I'm using RC7 in production already. See also https://www.npmjs.com/package/mobx/v/6.0.0-rc.7?activeTab=versions. Except for my issue with TS 4.x described above, it works fine (with mobx-react-lite v.3 beta https://www.npmjs.com/package/mobx-react-lite/v/3.0.0-beta.1).

However, you should be aware that there's no mobx-utils prerelease yet. See mobxjs/mobx-utils#276.

mweststrate · 2020-09-17T21:05:44Z

@bb thanks for pointing that out, after upgrading MobX to 4.0.2 the internal tests fail as well

mweststrate · 2020-09-17T22:37:49Z

New beta available:

mobx@6.0.0-rc.8
mobx-react-lite@3.0.0-beta.1
mobx-react@6.0.0-rc.4
mobx-utils@6.0.0-rc.1
Docs: https://deploy-preview-2327--mobx-docs.netlify.app/readme
Migration guide: https://deploy-preview-2327--mobx-docs.netlify.app/faq/migrate-to-6.html

I don't expect any API changes anymore, still polishing docs

bb · 2020-09-18T07:28:09Z

@mweststrate I confirm the TS 4.0.2 issue is fixed. Thanks a lot; both for fixing that and for releasing the mobx-utils RC.

roeycohen · 2020-09-20T13:08:24Z

so @mweststrate, decorators are out in v6? It doesn't exists in the new docs anymore, but will using them fail?

ar7casper · 2020-09-21T04:01:33Z

@roeycohen

so @mweststrate, decorators are out in v6? It doesn't exists in the new docs anymore, but will using them fail?

https://deploy-preview-2327--mobx-docs.netlify.app/best/decorators.html#how-to-enable-decorator-support

yordis · 2020-09-21T04:17:53Z

@mweststrate is there any concerns using MST with v6?

episage · 2020-09-21T06:59:30Z

I'd like to note that mobx@6.0.0-rc.8 does not seem to be tree shakable. No matter what you import, you end up with the whole bundle in all cases. Is this intentional?

Source: https://bundlephobia.com/result?p=mobx@6.0.0-rc.8

mweststrate · 2020-09-21T19:34:34Z

@yordis there is an open PR that should support MobX 6 fully. But I do not intend to release it personally as there are enough people and companies actually using the thing, benefiting from it but not really contributing back. So I leave releasing and double checking the update to the community, but the PR is here: mobxjs/mobx-state-tree#1569

mweststrate · 2020-09-21T19:36:59Z

@episage if I run it to terser's tree-shaking, I get results between 13.9 and 15.2 k depending on the imports (yarn test:size in the project). I think things could be better, so if someone wants to play with that feel free to take a stab at it, but I won't be further looking into it.

yordis · 2020-09-21T19:40:33Z

@mweststrate I am sorry, I am confused with what you said.

But I do not intend to release it personally as there are enough people and companies actually using the thing, benefiting from it but not really contributing back

Are you saying that people are using the package but they don't contribute back, therefore, you will no release a new version using mobx@v6?

So I leave releasing and double checking the update to the community

So we (the community) should take the lead on upgrading MST itself, and verify that works

Is that correct?

mweststrate · 2020-09-21T20:26:48Z

Exactly, I think all technical issues are addressed at this point. If someone steps as volunteer to take care of doing the final steps and releasing, and keep an eye on the project I'll gladly provide the necessary permissions. If nobody is interesting in investing time, I don't see any motivation / reason to put my time into it either :).

…

On Mon, Sep 21, 2020 at 8:40 PM Yordis Prieto ***@***.***> wrote: @mweststrate <https://github.com/mweststrate> I am sorry, I am confused with what you said. But I do not intend to release it personally as there are enough people and companies actually using the thing, benefiting from it but not really contributing back Are you saying that people are using the package but they don't contribute back, therefore, you will no release a new version using ***@***.***? So I leave releasing and double checking the update to the community So we (the community) should take the lead on upgrading MST itself, and verify that works Is that correct? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2325 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBDD6O77FQRAFAPWCHDSG6T4FANCNFSM4LZQ2B5Q> .

israelKusayev · 2020-09-24T20:40:44Z

Hey, I started to try mobx 6, and I have few questions and problems

here is the commit with the new mobx setup
reflexology/client-V2@b283e11

The example of combining multiple stores is a little bit confusing because all the stores are in one file.

Do I have to pass the instance of rootStore to all other stores? or it is just to share the data between the stores?

Also I'm getting typescript error about { rootStore: false }
Argument of type '{ rootStore: boolean; }' is not assignable to parameter of type 'AnnotationsMap<this, never>'. Object literal may only specify known properties, and 'rootStore' does not exist in type 'AnnotationsMap<this, never>'.ts(2345)
I saw the recommendation to use react context to insert the rootStore into the component tree, and I found this example, I guess if I have rootStore with multiple stores, I should pass the whole rootStore (instead of one store like you did in the example)

now when I want to use the store in react FC, do I need to do const rootStore = useContext(StoreContext);?

How can I get one store?

Thanks

mweststrate · 2020-09-30T16:37:29Z

Closing since released: https://michel.codes/blogs/mobx6

For any follow up questions, open a separate issue.

mweststrate added the ❔ question label Apr 1, 2020

mweststrate mentioned this issue Apr 1, 2020

[PoC] MobX 6 with codemod #2324

Closed

mweststrate added 🔨 breaking-change 💬 discuss 📖 documentation 🚧 experimental has PR and removed ❔ question labels Apr 1, 2020

mweststrate changed the title ~~Proposal: MobX 7: drop decorators, unify ES5 and proxy implementations, smaller bundle~~ 🚀 Proposal: MobX 7: 🧨drop decorators,😱unify ES5 and proxy implementations, 💪smaller bundle Apr 1, 2020

This comment has been minimized.

Sign in to view

trusktr mentioned this issue Sep 7, 2020

[[Define]] semantics causes libraries to lose performance. tc39/proposal-class-fields#320

Closed

trusktr mentioned this issue Sep 10, 2020

Decorators currently don't work with Babel lit/lit-element#234

Closed

mweststrate closed this as completed Sep 30, 2020

mobxjs locked as off-topic and limited conversation to collaborators Sep 30, 2020

mweststrate unpinned this issue Sep 30, 2020

🚀 Proposal: MobX 6: 🧨drop decorators,😱unify ES5 and proxy implementations, 💪smaller bundle #2325

🚀 Proposal: MobX 6: 🧨drop decorators,😱unify ES5 and proxy implementations, 💪smaller bundle #2325

Comments

mweststrate commented Apr 1, 2020 • edited Loading

MobX 6

Goals

🧨 1. Become compatible with modern ES standards

😱 2. Support proxy and non-proxy in the same version

💪 3. Smaller bundle

4. 🛂Enable strict mode by default

🍿API changes

Process

Timeline

spion commented Apr 1, 2020 • edited Loading

Bnaya commented Apr 1, 2020

urugator commented Apr 1, 2020 • edited Loading

xaviergonz commented Apr 1, 2020 • edited Loading

kubk commented Apr 1, 2020

danielkcz commented Apr 2, 2020 • edited Loading

This comment has been minimized.

mweststrate commented Apr 2, 2020 via email

mweststrate commented Apr 2, 2020

benjamingr commented Apr 2, 2020

benjamingr commented Apr 2, 2020

danielkcz commented Apr 2, 2020

mweststrate commented Apr 2, 2020 via email

benjamingr commented Apr 2, 2020

mweststrate commented Apr 2, 2020 • edited Loading

spion commented Apr 2, 2020 • edited Loading

benjamingr commented Apr 2, 2020

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

trusktr commented Sep 8, 2020

olee commented Sep 8, 2020

trusktr commented Sep 9, 2020 • edited Loading

urugator commented Sep 10, 2020

mweststrate commented Sep 10, 2020 • edited Loading

olee commented Sep 10, 2020

mweststrate commented Sep 11, 2020 via email

bb commented Sep 11, 2020 • edited Loading

olee commented Sep 13, 2020

stephy commented Sep 16, 2020

olee commented Sep 17, 2020

bb commented Sep 17, 2020

mweststrate commented Sep 17, 2020

mweststrate commented Sep 17, 2020

bb commented Sep 18, 2020

roeycohen commented Sep 20, 2020 • edited Loading

ar7casper commented Sep 21, 2020 • edited Loading

yordis commented Sep 21, 2020

episage commented Sep 21, 2020 • edited Loading

mweststrate commented Sep 21, 2020

mweststrate commented Sep 21, 2020

yordis commented Sep 21, 2020

mweststrate commented Sep 21, 2020 via email

israelKusayev commented Sep 24, 2020

mweststrate commented Sep 30, 2020

mweststrate commented Apr 1, 2020 •

edited

Loading

spion commented Apr 1, 2020 •

edited

Loading

urugator commented Apr 1, 2020 •

edited

Loading

xaviergonz commented Apr 1, 2020 •

edited

Loading

danielkcz commented Apr 2, 2020 •

edited

Loading

mweststrate commented Apr 2, 2020 •

edited

Loading

spion commented Apr 2, 2020 •

edited

Loading

trusktr commented Sep 9, 2020 •

edited

Loading

mweststrate commented Sep 10, 2020 •

edited

Loading

bb commented Sep 11, 2020 •

edited

Loading

roeycohen commented Sep 20, 2020 •

edited

Loading

ar7casper commented Sep 21, 2020 •

edited

Loading

episage commented Sep 21, 2020 •

edited

Loading