search

imgix / ember-cli-imgix

Easily add imgix functionality to your Ember application
https://imgix.github.io/ember-cli-imgix
MIT License
26 stars 13 forks source link

Uses Yarn in favor of NPM #49

Closed Duder-onomy closed 6 years ago

Duder-onomy commented 6 years ago

Description

Travis.ci is using yarn to make ember-cli-imgix builds. Ember-try is using yarn to make ember-cli-imgix builds. Yarn, at least for now, guarantees deterministic builds.

frederickfogerty commented 6 years ago

Hey @Duder-onomy. Long story short, I've used yarn many times across many different projects in the past, and it's come back to bite me many times. With the latest versions of npm it doesn't offer considerable benefits, and a quick look at the number of issues in both libraries (50 v 1000+) shows its inconsistency. Everything would be going great with yarn for a little while, and then something just wouldn't work - like bin files, or installing in parallel, or non-deterministic builds.

I hope it's clear why I'm hesitant to adopt yarn just for the sake of it.

In saying that, I'm happy to move to any tool which offers an advantage (such as yarn workspaces). Does package-lock.json not guarantee deterministic builds? What is the default in the ember community?

I see that ember and travis CI are using yarn for installing dependencies. Personally I'd like to see these changed to use npm rather than changing everything to use yarn.

frederickfogerty commented 6 years ago

Like just now

image

Duder-onomy commented 6 years ago

Yarn is the favorite in the ember community. Many ember projects need workspaces support (ember engines) and ember itself is a mono-repo. Also, Yehuda started writing yarn... so there is that.

I too have used NPM on countless projects with no issues, though that was always alongside npm shrinkwrap. I have never had an issue with Yarn and it DOES guarantee deterministic builds as NPM does not. (the yarn lock is actually useful)

The reason this started is I was trying to remove yarn from our travis config, but npm does not (and will not) support a npm install --from-lockfile and not also update the lockfile. So I could not get travis to run without also updating the package.json and making dirty the repo in the process. By design, the package-lock.json is basically useless. However, there are ways to run a git clean after each npm install so this is not a blocker.

Anyhow, at the end of the day this project is incredibly small and I don't really care as long as they are using the same system locally as we are using in CI.

It was easier to update the project to use yarn then to use NPM in CI.

Npm is fine as I don't think this project is big enough where a non-deterministic build will be a problem.

Duder-onomy commented 6 years ago

That is an NPM error (yarn uses the npm registry) NPM has been spotty all morning https://status.npmjs.org/

Duder-onomy commented 6 years ago

https://github.com/npm/npm/issues/18103 ^ Anyhow, not to go into it too deep as we don't have the time to hash out the entire npm / yarn history. Just trying to fix that damn build in #42 and I suspected that maybe it was version mis-matching.

I will re-open this if we see any real issues with NPM again.