Investigating this case, it's hard for us to deal with this because it's valid typescript.

TS augments the the base named thing with the namespace, so in this case, it is completely valid code.
The question is; should this should be caught by our linter if it's completely valid code?

We would have to bring in and redefine the no-redeclare rule to make this work.

Concrete code:

function CodeMirror(arg: string): boolean {
    return true;
}

namespace CodeMirror {
    export const foo = 1
}

CodeMirror.foo // type === number
CodeMirror("hi") // valid

Declarations only:

declare function CodeMirror(arg : string): boolean;

declare namespace CodeMirror {
    export const foo = 1
}

CodeMirror.foo // type === number
CodeMirror("hi") // valid

repl

@bradzacher right now parser is not providing consistent informations about declarations, than we can't really do much for now here.

+1 have also come across this issue.

Would be nice if declaration-merging was supported.

This also errors on global augmentations, which seems fixable to me b/c it actually only happens when wrapped in a declare global:

declare global {
  namespace jest {
    interface Matchers<R, T> {
      /**
       * Tests that the expected {@link TFBlockBody} contains only one {@link TFDynamicBlock}
       * with the given `name`
       *
       * @param {string} name
       */
      toContainTFDynamicBlock(name: string): R;
    }
  }
}

So you should just be able to look for the declare global and go off that.

Let me know if you'd like a separate issue to track this, or if I've missed something :)

Additionally, a question: is no-redeclare actually picking up errors that TypeScript itself isn't?

Aside from the potentially nicer error messages, I'm wondering how much value there is in actually having no-redeclare in a TypeScript codebase?

Just noticed it is actually turned off in the eslint-recommended config provided by @typescript-eslint/eslint-plugin, so that answers that question.

In response to your second comment - AFAIK it doesn't catch anything.
For these sorts of rules which catch things typescript catches itself, usually people use it because either:

• they have webpack builds wherein they use the typescript in isolated modules mode (or they use babel to transpile).
• they haven't thought about the fact that it does something TS does.

This duplicating a TS compiler error is why this issue (and really all scope analysis rules) have been sitting open for 1yr+++. To the core maintainers the issues are high effort + low value, and there's yet to be a contributor that has cared enough to look into it.

Merging into #1856