More detailed "Migrating from npm" guide

[donaldpipowitch]

Hi,

I'd like to know for all commands on "Migrating from npm" if and how they differ between npm and yarn. I can read about some of them in the docs. E.g. for add they tell When you run either yarn or yarn add <package>, Yarn will generate a yarn.lock file within the root directory of your package.

But how is yarns publish different to npms? It seems that this isn't just an alias. I initially thought yarn would be just for library consumers to install dependencies, but that library authors should still use npm to publish components. This doesn't seem to be true. So why should I use yarn publish? Is this just convenience to use only one package manager?

[markstos]

Comparing the docs for yarn publish to those for npm publish, they support the same subcommands and options. A difference is that the NPM docs mentions taking into account .gitignore and .npmignore files. The yarn publish docs don't mention these files and the yarn publish source code doesn't mention them either.

I don't think it's practical to maintain a detailed nuanced guide to the differences between every sub-command. That would involve tracking both projects as they change over time. The summary table is helpful to find the yarn command you need based on the npm command you are used to. Then you can review the detailed docs of the yarn command to confirm if it's going to work like you want.

[donaldpipowitch]

I probably wouldn't track them over time, but it would be nice to see why I should use yarn instead of npm right now after yarn was released.

If I understand you correctly it is currently not possible to ignore certain files? If this is true it would be nice to understand why the yarn team decided to do that? Or is this probably a bug? I honestly can't know that, because I can't find a place where publish is explained in detail. But there must be some motivation behind implementing a new publish which works differently to npm publish. And that's what I'd like to know :)

[markstos]

@donaldpipowitch the why yarn reasons are spelled on the front page of the https://yarnpkg.com/ I'm not a yarn core-contributor, but I am already using yarn in production primarily because the yarn.lock file much less headache prone for my team than shrinkwrap was. Secondarily, yarn commands run for faster for us. The increased priority of security and offline use are also interesting.

Ignoring files like npm publish does seems useful, so I would consider the lack of that in yarn publish to be an unimplemented feature. :)

I can't speak for the core-team motivation for having their own publish command, but it is convenient to have all the subcommands in one place, as npm did. It also opens the door to yarn having a separate or additional registry to publish in the future, but that doesn't exist now.

[donaldpipowitch]

It also opens the door to yarn having a separate or additional registry to publish in the future, but that doesn't exist now.

That would be one of the points which could be a motivation for an own publish and to hear something about that is exactly the reason why I created an issue like this.

I'm aware of other benefits of yarn mentioned on the front-page. We also use yarn, because it's faster and locks deps by default. As I mentioned in the first ticket that's also why I thought yarn would be for installing only and not publishing, because benefits or differences of publishing aren't explained in detail.

[jamiebuilds]

There really isn't a real strong benefit for publishing though. There's nothing to advertise as being notably better, it's all about the install process.

[donaldpipowitch]

So we could add something like this to the "Migrating from npm" page?

We added yarn publish for convenience so you don't have to switch between two package managers. It behaves basically like npm publish .

I think it is also important to note when something isn't different, so there is no room for speculation :)