11–20 of 22 posts
Earlier quoted context omitted.
> It also doesn’t understand how to get packages from a git source. Not sure what you mean. https://bundler.io/guides/git.html
He's talking about npm
...or with `npm i git+ssh:...`, and npm will git clone it locally, as long as it has a `package.json`
You can install a certain commit, or even from a Gist!
Earlier quoted context omitted.
It’s even worse when npm install modifies the package lock file. It also doesn’t understand how to get packages from a git source. From a release engineering perspective, this drives me batty.
i’ve said before that it’s like the npm people have made the worst possible design choice whenever asked for a decision. it’s insane how bad it is compared to bundler or comparable package management tools.
Earlier quoted context omitted.
i’ve said before that it’s like the npm people have made the worst possible design choice whenever asked for a decision. it’s insane how bad it is compared to bundler or comparable package management tools.
This is such a wild take. I’m constantly running into issues with bundler and literally never have issues with npm or yarn. Not to mention the amount of innovation happening within that world with module resolution algorithms.
The only problem I can really think of is working through issues when two gems require different irreconcilable versions of a library, and that's more of a fundamental ruby issue / design choice than a problem with bundler itself.
FWIW, I LOVE bundler and it absolutely kills me that npm, pip still haven't settled well in to the management of it. Specifically, bundler allows side-by-side version installs and the program simply loads the version specified in the bundle.lock thus making the lock file the source of truth where as npm, pip, even poetry install whatever version exists at the path. This pushes the source of truth from the .lock to th…
> Specifically, bundler allows side-by-side version installs and the program simply loads the version specified in the bundle.lock I'm surprised Python hasn't caught up to that. At best you can use Anaconda, but in order to have multiple versions of the same library, you end up having to create a new environment, which is another Python installation. There are currently some nasty dependency issues caused by 3.11->3.…
This can be done in the JS/TS world. It also occasionally breaks horribly in the JS/TS world. You might have multiple incompatible versions of a package in the tree when one dependency depends on one particular version, and the rest of your universe depends on another. It gets even worse when `Symbol`s come to play, since they'll be unique between those two versions.
Earlier quoted context omitted.
i’ve said before that it’s like the npm people have made the worst possible design choice whenever asked for a decision. it’s insane how bad it is compared to bundler or comparable package management tools.
No, I strongly disagree. Npm may have some weird ergonomics and defaults, but as a dependency manager it is first class. Before npm, almost all dependency managers suffered from the diamond dependency problem. Npm pioneered allowing multiple versions of packages to be simultaneously installed without having to chase down conflicting dependencies as long as the package involved is not a major framework (i.e. peer depe…
FWIW, I LOVE bundler and it absolutely kills me that npm, pip still haven't settled well in to the management of it. Specifically, bundler allows side-by-side version installs and the program simply loads the version specified in the bundle.lock thus making the lock file the source of truth where as npm, pip, even poetry install whatever version exists at the path. This pushes the source of truth from the .lock to th…
Do you mean it uses whatever version exists in the path? I think that's a fair concern.
Earlier quoted context omitted.
This is such a wild take. I’m constantly running into issues with bundler and literally never have issues with npm or yarn. Not to mention the amount of innovation happening within that world with module resolution algorithms.
Do you mind sharing some details? This doesn't match my experiences at all really - while I think running into messes with NPM is sometimes a little overstated, the number of times I've needed to do something drastic like `rm -rf node_modules` is not insignificant and I've never had to do anything at all like that with Bundler. The only problem I can really think of is working through issues when two gems require dif…
We had to pin our bundler to a specific version and it caused all sorts of issues when installing gems.
Earlier quoted context omitted.
Do you mind sharing some details? This doesn't match my experiences at all really - while I think running into messes with NPM is sometimes a little overstated, the number of times I've needed to do something drastic like `rm -rf node_modules` is not insignificant and I've never had to do anything at all like that with Bundler. The only problem I can really think of is working through issues when two gems require dif…
The biggest issue was with using older versions of ruby or older versions of the bundler itself. We had to pin our bundler to a specific version and it caused all sorts of issues when installing gems.
What you and I describe is not a bundler or npm problem so much that the software we are working on requires an outdated version of ruby and nodejs.
I agree with the the other comment though — npm has more problems even when with the latest version. Like Nodejs, it is flawed by design.
Earlier quoted context omitted.
i’ve said before that it’s like the npm people have made the worst possible design choice whenever asked for a decision. it’s insane how bad it is compared to bundler or comparable package management tools.
No, I strongly disagree. Npm may have some weird ergonomics and defaults, but as a dependency manager it is first class. Before npm, almost all dependency managers suffered from the diamond dependency problem. Npm pioneered allowing multiple versions of packages to be simultaneously installed without having to chase down conflicting dependencies as long as the package involved is not a major framework (i.e. peer depe…