5 ms·

Digging into the reason behind breakage, the change is this one: https://github.com/then/is-promise/commit/feb90a40501c8ef69b0c65bdf1eb703182214407#diff-b9cfc7f

• searchableguy 6y ago
  I wonder why people won't use yarn zero installs. They are great for having a reproducible builds and can work offline. You can have a CI and git hook which checks your code before deployment or pushing to git. Another way is to pin down the specific versions without ~ or ^ in the package.json so your updates don't break stuff.
  • ng12 6y ago
    Isn't this all stuff that you add after generating the project? For example yarn.lock is created on your first install. Having a pre-generated yarn.lock is a no-go because of the dubious decision to include the full path to the registry the package was sourced from.
  • jrochkind1 6y ago
    What's "yarn zero installs"? Googling did not do it for me.
    • _630w 6y ago
      Instead of node_modules containing source code of the packages, yarn generates a pnp.js file which contains a map linking a package name and version to a location on the disk, and another map linking a package name and version to its set of dependencies. All the installed packages are stored in zip form in .yarn/cache folder to provide a reproducible build whenever you install a package from anywhere. You can commit them to version control. Unlike node_modules, they are much more smaller in size due to compression. You will have offline, fully reproducible builds which you can test using a CI before deployment or pushing code to repository https://yarnpkg.com/features/zero-installs https://yarnpkg.com/features/zero-installs
      • brunoqc 6y ago
        That's awesome. Thanks!!
      • jrochkind1 6y ago
        This is a great feature I did not know about, thanks I don't understand how it applies to the OP problem. Even without "zero installs", yarn all by itself with a yarn.lock already ensures the same versions as in the yarn.lock will be installed -- which will still be a reproducible build as long as a given version hasn't changed in the npm repo. (It looks to me like "yarn zero" is primarily intended to let you install without a reliable network and/or faster and/or reduce the size of your deployment artifacts; but, true, it also gives you defense against a package-version being removed or maliciously changed in the npm repo true. But this wasn't something that happened in OP case was it? A particular version of a particular package being removed or changed in repo?) In this case, it was a new version that introduced the breakage, not changed artifact for an existing version. AND the problem occurs on trying to create a new project template (if I understand right), so I thin it's unlikely you'd already have a yarn.lock or a .yarn/cache? Am i missing something? Dont' think it's related to OP. But it's a cool feature!
        • deleted 6y ago
          [deleted]
        • searchableguy 6y ago
          No. It wasn't meant for OP (is-promise) because that would require tests for the imports. I saw some work around changing versions in the package.json and lockfiles in the github issue. Instead of that, you could just roll back to the previous commit. Way easier. The package author also changed the earlier version after fixing it. It would stop your shit from failing at least.
        • JonathonW 6y ago
          FWIW, yarn.lock (and the lockfile for recent versions of NPM, IIRC) also keeps package hashes-- so a build is either fully reproducible and pulls down the same artifacts as the original, or it fails (if an artifact is missing or has changed). `yarn zero` protects you against dependencies disappearing, and lets you install without network connectivity.
    • acemarke 6y ago
      That might be referring to Yarn's "offline mirror" feature. When enabled, Yarn will cache package tarballs in the designated folder so that you can commit them to the repo. When someone else clones the repo and runs `yarn`, it will look in the offline mirror folder first, and assuming it finds packages matching the lockfile, use those. This takes up _far_ less space than trying to commit your `node_modules` folder, and also works better cross-platform. I wrote a blog post about setting up an offline mirror cache a couple years ago: https://blog.isquaredsoftware.com/2017/07/practical-redux-part-9-managing-dependencies/#managing-dependency-packages-for-offline-installation https://blog.isquaredsoftware.com/2017/07/practical-redux-pa... Used it on my last couple projects at work, and it worked out quite well for us.
      • freedomben 6y ago
        That's quite interesting, although back in the day we did that for C dependencies that weren't packaged well, and it quickly ballooned the size of our repo since git has to treat tar balls as binaries. Even if you only update a few lines of the dependency for a patch version, you re-commit the entire 43 MB tarball (obviously that depends on the size of your tarball).
        • curryst 6y ago
          You could use Git LFS to store anything ending with a tarball extension. It's pretty well supported by most Git servers (I know GitHub and GitLab support it off the top of my head). You do need the LFS extension for Git to use it.
      • jwilliams 6y ago
        The other similar approach is to build in containers - and use Docker layers to contain the dependencies.
      • andrethegiant 6y ago
        verdaccio aims to do this as a proxy: https://github.com/verdaccio/verdaccio https://github.com/verdaccio/verdaccio
    • RobertKerans 6y ago
      Google "yarn plug and play", rather than "yarn zero installs". There isn't much in the way of details outside of the main Yarn website -- now focussed on Yarn 2 -- which has the documentation (vs Yarn 1.n, which does not have plug and play and works the same as NPM, and has now moved to classic.yarnpkg.com) (Edit: I'm not quite sure how this would have completely prevented the issue? P'n'p is very good and seems to be a real step forward for JS package management but surely the same issue could have occurred regardless?)
  • rclayton 6y ago
    - we’ve stopped using ^ and ~ because of the unpredictability of third party libraries and their authors’ potential for causing our own apps to break. We also find ourselves forking and managing our own versions of smaller/less popular libraries. In some cases, we’ve chosen to reimplement a library.
• franciscop 6y ago
  From those commits, it seems this issue was fixed in 1h12min. That should be a new record, specially considering this is all volunteer work on a Saturday. While it's bad that things break, the speed at which this was fixed is truly amazing. A big thank you to everyone involved here.
  • mikewhy 6y ago
    Not sure where you're getting 1h12 from. First issue was reported at 12:18pm (my time) final update that fixed it was published at 3:08pm. Not that long, but my issue with this release snafu is that: - the build didn't pass CI in the first place - the CI config wasn't updated to reflect the most recent LTS release of node - the update happened directly to master (although that's to how the maintainer wants to run their repo. it's been my experience that it's much easier to revert a squashed PR than most other options) - it took two patch versions to revert (where it may have only taken one if the author could have pressed "undo" in the PR)
    • chvid 6y ago
      This is a good example of how terrible messy JavaScript library creation is. There is no change to the actual functionality of the library. Only in the way it is packaged, here to support something that is an "experimental" feature in node. It is also something that is hard to write automated tests for.
      • qes 6y ago
        > This is a good example of how terrible messy JavaScript library creation is. Meanwhile over in .Net-land, after 15+ years of smooth sailing (5+ if you only count from the introduction of NuGet), the transition from full framework to .Net Core has made a multi-year long migraine out of packaging and managing dependencies. I ran into multiple scenarios where even Microsoft-authored BCL packages were broken and needed updates to resolve only packaging issues. It's a lot better now than during v1.x days, but I still have hacks in my builds to work around some still broken referencing bits.
• jbverschoor 6y ago
  Digging requires depth. 1 line modules aren’t depth.
• Aeolun 6y ago
  I’d argue that ‘index.mjs’ is a relative URL.