1. 28
  1.  

  2. 10

    This is a nice summary for someone who might have written JS a decade ago. It hits the main points in the field of ‘weird things you have to do to write JavaScript these days’. But there’s one major omission - package managers. I still have a hard time explaining to myself why we have bower, npm, and yarn all solving the same problem with varying degrees of success.

    1. 11

      Bower is officially deprecated. Yarn was created to solve problems that existed in npm < 5 [1]. With the release of npm 5+, you can ignore package managers other than npm at this point.

      [1] Exactly reproducible dependency trees & performance being the main ones.

      1. 1

        [1] Exactly reproducible dependency trees

        Did they remove the ability to re-publish a given version of a package? Hopefully - if not, this feature is just a cake-lie.

          1. 1

            Great! Do you have more info on the “reproducible” stuff? I am not finding mention of it.

            1. 1

              From the npm 5 release announcement:

              npm will --save by default now. Additionally, package-lock.json will be automatically created unless an npm-shrinkwrap.json exists. (#15666)

              This package-lock.json is what provides reproducible dependency trees. It’s the equivalent of Yarn’s yarn.lock.

              1. 3

                Well. I guess I have a different meaning of reproducible.. Previous versions of NPM would have variance in things like Makefiles that gyp puked out.. this meant that something that was “npm shrinkwrap’d” and then tar’d up, would be different every time. This is the reproducability I was hoping for.. guessing the lock file doesn’t give me that.. But I will play around and see.

                1. 2

                  Not sure if it’s possible to enforce that. You would need to ensure that any postinstall hooks are deterministic, so no calls to Math.random() or new Date().

                  You also would have to forbid making network requests, accessing the filesystem and really anything that leaves pure javascript land.

                  1. 1

                    Yeah. No idea about that aspect. :-/

          2. 1

            It still seems like yarn is faster, according to a few blog posts. The margin is much closer, however.

            1. 1

              If nothing else, it’s much more consistent. At my company I’ve been migrating our apps from using bower and npm packages to exclusively npm packages, and setting our build servers to use yarn instead of npm. It solved our issue with npm intermittently crashing our builds.

            2. 1

              I use yarn because it’s way faster than npm, doesn’t even compare. I develop under WSL though so maybe the difference is more noticeable there.

              1. 2

                I use yarn because it’s way faster than npm

                This has not been my personal experience. npm 5 has been consistently as fast or faster than yarn in my testing on Windows 10. YMMV.

                1. 1

                  I’ve just tried deleting the node_modules directory in my current project with 780 packages and ran npm install- it took 53s. Then I’ve done this again and ran yarn install and it finished in 27s. It’s possible it’s something specific to my project or to the fact that I’m running under WSL (maybe npm hits some under-optimised part of it), but anyway in my particular case it’s indeed faster with yarn.