flow

Weak mode allowed you gradually convert a file. Now you can gradually convert the project, one file at a time, but you can't work on a file here and a file there, not without fixing them completely. If there is no alternative I believe it defeats the entire purpose of flow..and people would just use TS instead, if the hassle is almost he same.

I was trying to get LSP working with Sublime Text 4, but Flow kept crashing due to the presence of non-ASCII characters in my source code. I was able to reproduce this with a small one-file project containing only : ``` :: -> flow textDocument/didOpen: {'textDocument': {'version': 0, 'languageId': 'javascript', 'text': '// @flow\n\n"”";\n', 'uri': 'file:///home/michael/code/sublime-flow-lsp-chr-issue/index.js'}} flow: Client fatal exception: (Invalid_argument Char.chr) flow: Starting Flow server flow: Raised at file "stdlib.ml", line 30, characters 20-45 flow: Called from file "src/hack_forked/utils/hh_json/hh_json.ml", line 183, characters 10-23 :: looks like flow doesn't like unicode-escaped characters like \ufffdabc. If I set ensure_ascii=False in the json encoder then it doesn't crash [...] but now it looks like it doesn't understand utf-16 column offsets. Oh well, I don't think many people will use utf-16 surrogate pairs in their code He submitted a workaround at https://github.com/sublimelsp/LSP/pull/1701 which I'm very thankful for, but it sounds like something that can be better handled in Flow too!

Proposal utility type creates a read-only view of T. As such it does not model properly the effect of as a reference to T can be assigned to allowing to change the view via modifying the reference of the original type. To address that it will be nice to have utility type. A mutable T or cannot be assigned to while can be assigned to . The only way to create instances of is to use . This will allow to catch a missing call to . Use case Consider the following code: It presently type-checks and does not detect a missing call to while the intended version should be: Moreover, the bug is not detected by JS runtime at the point of foo.field assignment leading to rather hard to debug issues. This is especially actual in the code that uses immer-style libraries with the notion of draft objects that should be frozen when stored in persistent data structures. It is possible to workaround the issue using a wrapper type like: But this requires to create an extra objects at runtime witch brings an overhead over the original solution. Another possibility is to create a synthetic type for the mutable object that cannot be assigned to Foo like in: While this does not impose any runtime overhead, it still requires an ugly hack with a never assigned field and the any type and the error message is not ideal: In addition this hack does not work with arrays. With the code becomes: