```javascript
  var foo = {
    a: true, // Find all references on "a" here...
    b: "hello"
  };

  foo.a = false;
  bar(foo);

  function bar(obj) {
    obj.a = false; // Won't find this "a".
  }

  ```

  ```typescript
  interface Foo {
    a: boolean;
    b: string;
  };

  var foo: Foo = {
    a: true,   // Find all references on "a" here...
    b: "hello"
  };

  foo.a = false;
  bar(foo);

  function bar(obj: Foo) {
    obj.a = false; // Will be found, renamed if refactored, etc..
  }

  ```

There is some support for JsDoc in the engine, so code like the below will work:

  ```javascript
  /** @typedef {{a: boolean, b: string}} Foo */

  /** @type {Foo} */
  var foo = {
    b: "hello"
  };

  foo.a = false; // Find all refs here
  bar(foo);

  /**
   * @param {Foo} obj - Some object
   */
  function bar(obj) {
    obj.a = false; // will find this one
  }

  ```

Disclaimer: I'm working on a competing tool

If a particular function can be tied to particular variable from scoping block, then the function is not entirely useful. On the other hand, if a function is general and has the same argument name as variable from scoping block, which is going to be passed in, mentally it is difficult to analyse the function without thinking about the variable which may shadow bugs in function. E.g. square root function may omit negative argument check, because variable from scoping block is always positive.

Instead of knowing scoping rules I advocate for distinct variable names, so scoping rules (name shadowing) do not even come into play.

  function Person(name) {
    var person = this;
    person.name = name;
  }
  
  var person = new Person("Jon Doe");
  
  alert("Welcome " + person.name);

  person.name = "Harry Houdini";

  // ES6 example:
  var messages = people.map( person => person.name += " is a rock star" )

As you work on this, do you know if the refactoring tools would fully work with my code typed with Flow instead of TypeScript?

(I use the official flow-for-vscode extenstion, idk if it's relevant)

Edit: Ok I just tried and it works, even with the extension disabled.

  type Foo = {
    a: boolean,
    b: string,
  }

  var foo: Foo = {
      a: true, // Find all references on "a" here...
      b: "hello"
    };

  foo.a = false;
  bar(foo);

  function bar(obj: Foo) {
    obj.a = false; // Found it.
  }

- If you don't have any calls to the function yet (i.e. "bar(foo)" wasn't there above), then there is nothing to infer from, so you have no idea what the type is at this point (other than by the use of the parameter inside the function).

- Is your call-site wrong? If the parameter type is explicit, this is easily checked. If not, then again you can only go by what the function does with it. (Which may not be much help if it's something like "RestAPI.post(JSON.stringify(theParamInQuestion))" ).

I didn't downvote, but this seems incorrect to me. I'm sure that it works in small code bases, but once your code gets large enough (and dynamic enough) it's going to have to start missing things.

My current project has 10,000 LOC and 130 files. If I use "Rename symbol" on something imported in different files of my project, the editor will open all the files, edit all the names and just wait for me to save the changes.

However Brackets does better at finding method definitions. Even in my mess of a project with non typed JS, Brackets can always find the method definition or at least give me possible choices.

Their algorithm always fails on certain cases. If your code base is larger, it's more likely to contain those cases.

Example case that will always fail:

    const x = { foo: () => {} }
    x["f" + "oo"]();

Yes, this is a contrived case, but we had similar code in production at my last job.

With good coding practice, references, "senders" and "implementers," and renaming worked well in Smalltalk. Where I missed types was during refactoring, and that also worked well about 99% of the time without types. It was that one last thing that we couldn't be 100% sure of that blocked the big refactoring we all wanted to do badly -- that's when I missed types!

I last looked as VSCode (on a KDE 4 CentOS 7 desktop) about half a year ago, and it was terribly slow, even without extensions.

I'd really recommend trying it again. On a performant machine, VS Code feels like a native app to me aside from a slightly slower start up time, whereas Atom is noticeably slow. On my bottom spec 12" Macbook the difference is more noticeable, but everything feels slow on there.