• unsaid0415@szmer.info
    link
    fedilink
    English
    arrow-up
    73
    arrow-down
    51
    ·
    1 year ago

    I recently made a small pure JS package at my company. It just fucking worked, can you believe it? No setting up compilation and CI/CD for build + release. Just put it in the repo and publish manually, and it just worked, it’s ridiculous

    • magic_lobster_party@kbin.social
      link
      fedilink
      arrow-up
      122
      arrow-down
      1
      ·
      edit-2
      1 year ago

      CI/CD is useful regardless of which language you’re using. Sooner or later some customer is going to yell at you because you didn’t discover the fatal error before deploying.

        • AstridWipenaugh@lemmy.world
          link
          fedilink
          arrow-up
          51
          arrow-down
          1
          ·
          1 year ago

          CICD isn’t an alternative to testing your own work locally. You should always validate your work before committing. But then once you do, the CICD pipeline runs to run the tests on the automation server and kicks off deployments to your dev environment. This shows everyone else that the change is good without everyone having to pull down your changes and validate it themselves. The CICD pipeline also provides operational readiness since a properly set up pipeline can be pointed to a new environment to recreate everything without manual setup. This is essential for timely disaster recovery.

          If you’re just working on little projects by yourself, it’s usually not worth the time. But if you’re working in anything approaching enterprise grade software, CICD is a must.

          • jabberati@social.anoxinon.de
            link
            fedilink
            arrow-up
            0
            ·
            1 year ago

            @Stumblinbear I only worked on small projects so far, that’s probably why I don’t understand it. But a merge commit is like any other commit and the person pushing this commit has to make sure it works.

            • Stumblinbear@pawb.social
              link
              fedilink
              arrow-up
              1
              ·
              edit-2
              1 year ago

              When working in teams, merging in two pull requests with seemingly unrelated changes is common practice. If I had to rebase and re-run tests every time another PR got merged in while mine was awaiting reviews, I’d spend most of my time running tests

    • 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.

      • Pyro@lemmy.world
        link
        fedilink
        English
        arrow-up
        9
        arrow-down
        2
        ·
        1 year ago

        I thought it was clear: they’re implying JS is simpler/faster to write and deploy because transpilation is necessary when using TS (unless you use a modern runtime).