Why does yarn init -2 add EditorConfig

[aentwist]

Why does the recommended installation method add EditorConfig? Is it necessary for yarn to work?

If it is just 'we like EditorConfig', then I would suggest removing this off-topic design choice? I would like to use Prettier, and only Prettier.

If you are unwilling to remove this, could it at least be moved into a non-default CLI option?

It feels like bloatware on cell phones. Why not just let users choose?

If nothing else, hopefully this issue evolves into a fruitful explanation for this 'feature'.

[polarathene]

It adds a few more files actually, and it's trying to be helpful because this isn't a command to install yarn per se, that's kind of an indirect part of -2.

The yarn init command is initializing a new project for you with the latest stable yarn release (3.6.3 currently).

$ cat .editorconfig
root = true

[*]
end_of_line = lf
insert_final_newline = true

[*.{js,json,yml}]
charset = utf-8
indent_style = space
indent_size = 2


$ cat .gitattributes
/.yarn/**            linguist-vendored
/.yarn/releases/*    binary
/.yarn/plugins/**/*  binary
/.pnp.*              binary linguist-generated


$ cat .gitignore
.yarn/*
!.yarn/patches
!.yarn/plugins
!.yarn/releases
!.yarn/sdks
!.yarn/versions

# Swap the comments on the following lines if you don't wish to use zero-installs
# Documentation here: https://yarnpkg.com/features/zero-installs
!.yarn/cache
#.pnp.*


$ cat .yarnrc.yml
yarnPath: .yarn/releases/yarn-3.6.3.cjs


$ cat package.json
{
  "name": "tmp",
  "packageManager": "[email protected]"
}

.yarn/releases is also populated with the yarn version it installs for you, only local for that project with this version. yarnPath is the old way and you really aren't likely to want to commit that to your repo. If you do, you probably want to use Git LFS, or you're ok with the fact that each time you update this yarn version it'll bloat up your git repo.

Realistically you'd want to commit your package cache too for zero-installs, and that's still not enough to really self-contain everything (which is the goal of reproducible builds), since over time the project can become incompatible with Node runtimes too... I'm not a fan personally and if that's important to you there are better ways to backup/archive a project (depending on your requirements).

---

Just noticed the date you asked was Mar 2022. This was referenced from someone asking a similar question more recently. Docs or behaviour may have differed since you asked.

Correct approach is with corepack now, not yarn init IMO: #5744 (comment)