• jmk1ng
    link
    fedilink
    arrow-up
    60
    arrow-down
    4
    ·
    1 year ago

    Did it work? How do you know that? A consumer of your package sends a int when your package expects a string.

    What now?

    • sik0fewl@kbin.social
      link
      fedilink
      arrow-up
      46
      arrow-down
      1
      ·
      1 year ago

      Consumer just needs to write 4x as many unit tests to make up for lack static typing. Hopefully the library author has done the same or you probably shouldn’t use that library.

      • marcos@lemmy.world
        link
        fedilink
        arrow-up
        6
        ·
        1 year ago

        4x as many unit tests

        Well… the people fighting against TS are simply not testing things thoroughly. So they are not writing those tests.

        Some times that’s even perfectly ok. But you don’t want to build things over a complex library that has this attitude.

        (Except for svelte. It’s meaningless for svelte, as TS was always a really bad fit for it.)

    • Null User Object
      link
      fedilink
      arrow-up
      3
      arrow-down
      20
      ·
      1 year ago

      Theoretically, they’ll test and notice that doesn’t work and fix their code before they deploy it to production.

      • The Quuuuuill@slrpnk.net
        link
        fedilink
        English
        arrow-up
        7
        arrow-down
        1
        ·
        1 year ago

        Where can you point to other developers evidence that the code in git matches the code you deployed? Deploying locally built packages to prod is an automatically fireable offense because its not auditable

        • Null User Object
          link
          fedilink
          arrow-up
          1
          arrow-down
          1
          ·
          1 year ago

          WTF are you talking about? All I’m saying is that if you write code (that in the context of this discussion passes arguments to a method you didn’t write, that may not be the type the author of the method expected someone to pass, but really, that’s completely beside the point), you should, oh, I don’t know, maybe test that it actually works, and maybe even (gasp) write some automated tests so that if anything changes that breaks the expected behavior, the team immediately knows about it and can make appropriate changes to fix it. You don’t need a strongly typed language to do any of that. You just need to do your job.