There's a lot of nuance to that statement. Most languages, including e.g. Java or Typescript, would not be strongly typed according to your definition, because their type system is "unsound": there are known cases where the type system does not protect you and the types are wrong. We generally still call these languages strongly typed.

In Typescript this is by design. The most obvious is array variance. Typescript makes them covariant because that's what a lot of sane TS and JS code uses them as, but they should be invariant because you can write to them.

Example:

   const dogs: Dog[] = []
   // A sound type system would error here,
   // but there's too many useful cases where you want to do this
   const animals: Animal[] = dogs 
   animals.push(new Cat())
   animals[0].bark() // runtime TypeError here

Okay, so I'm not crazy for thinking that declaring an empty, typed array as `const` and then writing/pushing to it is confusing/feels wrong.

I didn't go to college for software engineering or anything so when I ran into that for the first time I assumed there must have been some good academic reason that was simply beyond me as to why it was done that way.

It turns out that no, it's just as weird to those that do have the formal background, boy am I feeling vindicated ;)

I may be missing something, but your example doesn't typecheck?

  class Animal { }
  class Dog extends Animal{
    bark(){return 1}
  }
  class Cat extends Animal{
    bark(){return 1}
  }
  const dogs: Dog[] = []
  const animals: Animal[] = dogs
  animals.push(new Cat())
  animals[0].bark() <<<<< "Property 'bark' does not exist on type 'Animal'."

I would have called this “strictly typed” I think, not “strongly”. Maybe my terminology is off.