Weak Mode

[wbeard]

Hi there,

I'm curious why weak mode is being removed? I didn't find any issues regarding it and would advocate for it staying around.

It makes incremental adoption of flow much easier for those of us who are attempting to add it to a codebase that was largely written without the guard rails that typing provides. Just recently we've decided to start using weak mode on the areas of code proving to be costly to type.

The add any workaround is nice, but seems to make adopting flow incrementally much harder. Could anyone shed some light on why this decision was made?

[avikchaudhuri]

@wbeard The main reason was that it wasn't maintained and had rotted to the point where it was unclear what it was doing. There was absolutely no predictability / specification. Tomorrow we could make a change that would cause @flow weak to either miss more errors or suddenly start reporting more errors.

I agree that such decisions should be taken more openly: we should have created an issue to discuss it. Instead the core team agreed (1) removing it was good to clear technical debt and minimize confusion among new users (2) something like weak mode is potentially useful for incremental adoption but needs to be designed more deliberately.

[wbeard]

@avikchaudhuri Thank you for the quick response. I understand rot and tech debt are expensive, and appreciate the care your team is taking in making the best decisions possible to ensure this project is successful.

I would challenge that this feature helps the incremental narrative of flow and is worth having. Maybe not keeping in its current state, as it sounds like it's too expensive to maintain, but a replacement for it. I love that flow infers, rather than labeling anything not annotated as any. Our team tries to take advantage of the inference where possible. But, we also like the shortcut that weak mode provides us in adopting flow.

[object88]

Is there a deliberate design for a replacement other than littering code with any, which adds meaningless clutter? We are attempting to introduce @flow to a project with tens of thousands of JS files, and are facing pushback from some teams, because it can be very difficult to type a complex existing codebase, even with @flow's incremental approach. Having @flow weak gets the foot in the door for developers to start seeing benefits with a minimum of pain.

[avikchaudhuri]

I was going to suggest that one intermediate fix might be to tweak the flow suggest command to emit any for all declarations, to get a starting point for a file like @flow weak.

@object88 I would argue that typing one file completely with @flow is better than typing multiple files with @flow weak. A module is a good unit to reason about, modularly.

[object88]

@avikchaudhuri, I agree, however, I am whole-heartedly in the "More Flow Please!" camp. My issue is attempting to convince others to start adopting @flow. Our usage of @flow weak is centered around getting people starting, to be able to consume the strong typing that others have done, in the hope that they will then decide to engage further.

[object88]

@avikchaudhuri , I'm going to assume that @flow weak will be going away in the next release. I'd like to point out that there are 4500+ instances of it across github, and that could be a surprising change if the tool treats @flow weak as @flow.

Can you give some insight as to what the behavior will be once this change is released?

[avikchaudhuri]

@object88 I'll update on this thread soon. Thanks for the thoughtful feedback. The next release was already cut before this got committed so doesn't include this change. The next to next, yes.

[object88]

That would be very appreciated; thanks @avikchaudhuri .

[gabelevi]

We've reverted the removal of weak mode in time for v0.40.0. We may remove weak mode in the future, but we won't do it without having something better to replace it.

[object88]

This is fantastic news! Thank you very much -- I personally very much appreciate your listening to our feedback, and our team will benefit from the continued support.

[mikeaustin]

Should weak mode be working then in 0.45.0? I'm writing a language that compiles to ES3, and it's sure not happy, even when I use "// @flow weak" and/or "flow check --weak".

I assume I could target ES6/Babel, but that would require extra compilation steps. But then again, I may need it for flow-remove-types. Hmm.

"use strict";

// @flow weak

Array.prototype.foo = function () { }

Mikes-MacBook-Pro:impulse-js mikeaustin$ flow check --weak
test.js:5
5: Array.prototype.foo = function () { }
^^^ property foo. Property not found in
5: Array.prototype.foo = function () { }
^^^^^ Array