• PoopMonster@lemmy.world
      link
      fedilink
      arrow-up
      37
      ·
      1 year ago

      Just as irritating as seeing people use linters only to have a lot of files with @ts-ignore all over the place… Like why even bother?

      • master5o1@lemmy.nz
        link
        fedilink
        arrow-up
        5
        ·
        1 year ago

        oh you’ve got a private variable that I want to use? No worries, (foo as any)[‘secret’].

    • fusio@lemmy.world
      link
      fedilink
      arrow-up
      9
      ·
      1 year ago

      using any is actually much worse than using TS, because you’re basically telling the compiler “don’t help me here”… at least with JS the IDE is gonna help you… :/

    • xmunk@sh.itjust.works
      link
      fedilink
      arrow-up
      4
      arrow-down
      3
      ·
      1 year ago

      I don’t follow, stamping every function with : any lets you merge the branch and deploy it… trying to properly type everything extends the initial migration time likely to a level where management just says no.

      • folkrav@lemmy.world
        link
        fedilink
        arrow-up
        5
        ·
        edit-2
        1 year ago

        Use a combination of allowJs and ts-ignore, do progressive enhancement, and convert your codebase file by file. Adding any everywhere literally turns off type checking altogether codebase wide, including type inference. It also means a huge PR that’s both just noise that needs to be fixed later, and messes with your git history (good luck getting anything useful out of blame or bisect now).

        Just getting a green build doesn’t mean things are okay. You’re worse off than before doing that.

        • xmunk@sh.itjust.works
          link
          fedilink
          arrow-up
          2
          ·
          edit-2
          1 year ago

          I disagree that you’re worse off (the core of my comment was that even a shitty migration encourages better practices)… but I wasn’t super familiar with TS hinting - using ts-ignore would be preferable.

          Personally, I mostly work in PHP and we use a similar system. Strict typing is default off so we’ve slowly propagated declare(strict_types=1); to enable compile and runtime checking on a per file basis.

  • alokir@lemmy.world
    link
    fedilink
    arrow-up
    48
    ·
    1 year ago

    It’s a good way to get started, and then incrementally type as much as you can, preferably everything.

    Later on, or if you start a new project with TypeScript, it’s a good idea to turn on noImplicitAny and only allow explicit any in very specific framework level code, unit tests or if you interface with an untyped framework.

    The hassle really pays off later.

    • fusio@lemmy.world
      link
      fedilink
      arrow-up
      20
      arrow-down
      1
      ·
      1 year ago

      this is terrible advise - you should be using unknown. using any you’re basically disabling TS and will be under the false assumption that your code is ok while it’s most likely missing a lot of runtime checks

    • ryannathans@aussie.zone
      link
      fedilink
      arrow-up
      1
      arrow-down
      9
      ·
      edit-2
      1 year ago

      But if your code ever integrates with javascript you still need any everywhere so it’s pretty pointless

      • 9point6@lemmy.world
        link
        fedilink
        arrow-up
        8
        ·
        edit-2
        1 year ago

        Not true, in the absolute worst case, unknown is what you should be reaching for, but it’s pretty rare that you can’t create some kind of type to interface with JS if it’s not already got types. You can even use jsdoc comments as type hints in the JS too if you own that code.

        My not particularly hot hot-take: There’s basically no legitimate use case for any apart from “I don’t have time to type all this now, because I’m converting a massive project from JS to TS”

        • jana@leminal.space
          link
          fedilink
          English
          arrow-up
          4
          ·
          1 year ago

          There are some cases where any must be used instead of unknown but they usually involve generic constraints and seem more like a bug than intended behavior

      • alokir@lemmy.world
        link
        fedilink
        arrow-up
        4
        arrow-down
        1
        ·
        1 year ago

        Not necessarily, depending on your situation you can type the JS code yourself.

        If the team making the JS code were using jsdoc then the Typescript compiler can recognize the comments and use it for type checking.

        In some instances the compiler can infer types from JS code to do some basic validation.

        Even if the external JS code is recognized as any, your own code that’s using it still has types, so it’s better than nothing.

  • Max-P@lemmy.max-p.me
    link
    fedilink
    arrow-up
    5
    arrow-down
    10
    ·
    1 year ago

    I wish I did that, at this point my TypeScript template errors are as long as C++'s ._.

    • alokir@lemmy.world
      link
      fedilink
      arrow-up
      17
      arrow-down
      1
      ·
      1 year ago

      Typescript is a language, Node is a platform and framework. You can use Typescript in your Node project, they’re not mutually exclusive.

      The way I see it Typescript is more popular than ever, almost all (popular) libraries come with types and every job offer I get they use Typescript.

      And with good reason, our team recently took over a small Javascript app and there are tons of bugs that would never have existed if they were using Typescript. Things like they refactored something but missed to update a reference, or misspelled a variable name, failed to provide a required parameter to a funcrion, referenced a field that existed in another config object etc.

        • I’m not sure this proposal can replace Typescript. It doesn’t support any of the more powerful Typescript features as far as I can tell. Basic types in Javascript are a great step forward, but I don’t expect them to be very popular if they can’t describe things like partial JSON objects for working with APIs.

          Out of all the transpiler steps in “modern” JS, I don’t think I’ve ever seen Typescript suck up all that much performance. Splitting code into streaming files, doing whatever dark magic makes modern JS compatible with IE 9 for some reason, and setting up hot reloads used to be the heaviest part of my workflow. Working with Typescript sucked up a lot of RAM in my IDE, but that as mostly because the types I was working with were created in Javascript that read like code golfing sometimes, generating three or four types for every possible API call.

    • xmunk@sh.itjust.works
      link
      fedilink
      arrow-up
      5
      arrow-down
      1
      ·
      1 year ago

      Managing a node project is like juggling twelve barrels full of monkeys… and those monkeys have rabies. Trying to keep all your dependencies in line is insane.

      • scubbo@lemmy.ml
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        It is absolutely insane to me that people rag on the Python packing ecosystem when TypeScript exists. Sure, Python’s not perfect (Rust and Go seem better, from the small amount I’ve dabbled with them), but way easier and more stable than any TS project I’ve worked on.