[Feature] Init routine can be further improved

[TimonLukas]

• [x] I'd be willing to implement this feature
• [ ] This feature can already be implemented through a plugin

Describe the user story

I was surprised to see that yarn init generates a few additional files (following #1500). It's a good feature and improvement! But there are two points that IMO could be improved (hopefully relatively easily):

• The generated .editorconfig file is generated in a way that makes it apply some rules to all files and some to all JS etc. files. From a user perspective this is unwanted behavior.
• The .gitignore entries are only generated if the .gitignore file doesn't already exist. I usually let the file be generated by Github while creating the repository. For these cases it would be nice if the entries are appended. At least I can't think of many cases where a user has a .gitignore and doesn't want to ignore .yarn...
  • Technically this also applies to .gitattributes, although I never have one aside from ignoring .yarn stuff.

Describe the solution you'd like

• Change the .editorconfig to only apply to Yarn files
• Append the .gitignore entries if the file already exists
  • If wanted this could also be applied to .gitattributes.

Describe the drawbacks of your solution

• No drawback for the .editorconfig change
• Some people might not like the .gitignore change

Describe alternatives you've considered

-

Additional context

-

[SagnikPradhan]

Last time I checked the .gitignore used in creating repository in Github, it did not contain Yarn 2's ignored files. But the Node.gitignore on master branch of gitignore repository does contain it which is used by them. (Not sure why it is not the same)

My point being yarn should use it.

[arcanis]

Change the .editorconfig to only apply to Yarn files

Trying to better understand - what's the problem exactly? Does it use settings different from what you'd use? If so, you can use initEditorConfig to override the defaults by your owns.

Append the .gitignore entries if the file already exists

I agree, I think that in general it would make sense to provide some "edit in-place" support (for example, adding the workspace fields when running yarn init -w on a non-workspace repository).

Last time I checked the .gitignore used in creating repository in Github, it did not contain Yarn 2's ignored files. But the Node.gitignore on master branch of gitignore repository does contain it which is used by them. (Not sure why it is not the same)

The problem I see is that they're gitignoring the cache by default, which is the opposite of what I'd want to do. Perhaps this can be fixed on their side, though 🤔

[TimonLukas]

Trying to better understand - what's the problem exactly? Does it use settings different from what you'd use? If so, you can use initEditorConfig to override the defaults by your owns.

Based on this point in PR #1500:

add an editorconfig with the configuration that we use for the .json / .yml files that we generate (also .js as a bonus, but that can be easily overridden in the configuration)

I assumed that you meant the file to only be applicable for files generated by yarn (I somehow thought the .js part was about .pnp.js). I found this behavior to be pretty surprising. I see that it makes sense for yarn init to be the one command that sets up your project the way you want to. Personally I'd assume that it per default only sets the project up in a way that sets settings for yarn-generated files (i.e. the .gitignore makes a lot of sense to me), while other settings (e.g. indentSize: 2) would be available opt-in. But if nobody complains there probably is no good reason to change this?

Thinking about it, I was honestly mostly confused why there was a new .editorconfig file that applies to all JS files etc. (I kinda assumed it somehow got generated by WebStorm). Maybe adding some CLI output that explains which files were generated/touched (incl. a quick tip for how the defaults can be changed) would make this behavior more obvious.

I agree, I think that in general it would make sense to provide some "edit in-place" support (for example, adding the workspace fields when running yarn init -w on a non-workspace repository).

That makes a lot of sense. My naive approach would be to just append to the files for now, do you have something more intricate in mind?

@SagnikPradhan Good to see they are updating it! I generated the project using a Github Enterprise instance, it will take some time for the updates to be applied. I also just created a new repository - it's currently missing, but surely will be added soon. Using that as a base file sounds like a good idea :)

[arcanis]

I assumed that you meant the file to only be applicable for files generated by yarn (I somehow thought the .js part was about .pnp.js).

I initially built this for two reasons:

• I noticed that each time I created a new project, I had to go to the editorconfig website and copy-paste their config plus adapt a few settings to match the typical JS formatting.

• VSCode wasn't correctly detecting that JSON and YAML files were expected to have two spaces. While in this case it was about Yarn's files, I suspect you don't like when some files have a different indentations from others, so I didn't made it exclusive to our files.

Basically, this editorconfig it's an acknowledgement that pretty much every project wants to have uniformized indentations, and fortunately editorconfig is a very common solution for that, so by default we add rules for the file types you're most likely to use after creating the project (probably should add ts/tsx/jsx actually 🤔).

Note that there is one "bug", in that we don't respect the editorconfig when persisting the JSON / YAML files on disk. We ideally should, but that would imply some extra step to find the local config, which I'd prefer to avoid for now (since I suspect 2 spaces being the most common setting).

Maybe adding some CLI output that explains which files were generated/touched (incl. a quick tip for how the defaults can be changed) would make this behavior more obvious.

If we can find a visually appealing display why not 🤔

That makes a lot of sense. My naive approach would be to just append to the files for now, do you have something more intricate in mind?

In the case of JSON they'll have to be merged (using updateConfiguration to preserve the formatting), but that shouldn't be too complex overall 👍