Include other editors than JetBrains in the .gitignore

[springdo]

Hello,

I would like to include some other editors such as Eclipse in the workspace exclude for the .gitignore. Happy to PR if you feel appropriate

[vpanjganj]

Yes, please go ahead, thanks.

[bluepeter]

Honestly, the .gitignore is some kinda of crazy... why such an elaborate one? These are things that should be configured on a case by case basis... and really, many of these feel as though they belong in user dir, vs project dir.

[bluepeter]

A ~600 line default .gitignore is just asking for trouble... and is going to scare off new users from editing it to tune to constantly changing needs.

[vpanjganj]

@bluepeter What do you suggest? Maybe we can promote one of these .gitignore generator tools?

[bluepeter]

I'm not sure, but this feels honestly counterproductive. Some people will assume this is the "default" and go with it. As a result, they will get something completely counterproductive such as:

### Web ###
  | *.asp
  | *.cer
  | *.csr
  | *.css
  | *.htm
  | *.html
  | *.js
  | *.jsp
  | *.php
  | *.rss
  | *.xhtml

... which I can't ever imagine every being useful?

I'd honestly scrap it. It requires too much configuration. Havent' looked at any of the generators. Perhaps, instead, give some common-sense advice on rationale behind .gitignore strategies... e.g., why they shouldn't check-in node-modules/ etc.

[springdo]

It is very unweildy at the moment the .gitignore - perhaps the suggestion here is not to include ALL of this as what you'd include in your project but examples for common project types? Or groupings for tech types? It's always handy having a gitignore to hand when starting a new project

[antony]

@bluepeter is right. keep your IDE ignores on your machine. Nobody needs to ignore an enitre IntellIJ IDEA file-based project structure when they use tmux+vim for development.

Best to keep .gitignore focussed on global ignores specific to the project.

[vpanjganj]

The reason I put editors in there was based on my own experience. I had to delete someone else's .idea folder from repos.

[antony]

@vpanjganj and I absolutely have experienced the same thing - but rather than pollute .gitignore I think this scenario is a good time to educate other collaborators about the ability to have a local set of .gitignores for such things. It comes down to discipline, much like following a set of project guidelines like this :)

[yeskunall]

I see the need to ignore .idea and other files and folders generated by IDEs to manage project settings, but what about cases where pushing those configurations is encouraged, for example, in the case of people using vscode? In that case, it makes sense to push .vscode to enhance the developer environment.

A ~600 line default .gitignore is just asking for trouble

I actually agree with @bluepeter on this one. From what I understand, that .gitignore was created by pulling the data from gitignore.io, so I'd like to make a suggestion:

Maybe we can expand on the section for .gitignores. We can start by mentioning that the .gitignore for a specific project varies greatly based on the development environment (editors, IDEs, OS) and the technologies used in that project. (Node, Go, PHP, etcetera) Keeping that in mind, we can break that large .gitignore file into smaller chunks and point to the different .gitignores according to the project needs and requirements.

Thoughts?

[skyrpex]

I would just add rules to the gitignore that are related to the project, not the editor. For example, node_modules and .log files. Other things should be globally ignored by the user.

[vpanjganj]

in the case of people using vscode?

I think the current config for vscode handles that. You most likely want to push tasks.json etc...

### VisualStudioCode ###
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json

A ~600 line default .gitignore is just asking for trouble

I agree with that as well, I think this file should be trimmed down.

Go, PHP, etcetera, Keeping that in mind

I think we stick to be guidelines for JavaScript projects for now and do it right, this also prevents the docs from getting enormous.

My suggestion is:

• Adding the major Javascript IDEs (how many are they 5? 6?)
• Adding default OS files that we usually add to .gitignore,
• node,javascript usuals (node_modules, *.log, etc...)

[vpanjganj]

@skyrpex

Other things should be globally ignored by the user.

You know what, I think you're right. In that case we can have a small description on how each developer should set a global .gitignore and then as you said, add the usual ones (node_modules etc...)

[antony]

If I were to create a new project I'd start with an empty .gitignore. I'd then add *.log, and node_modules in the first few commits.

Beyond that my .gitignore files are generally quite empty, for frontend projects I'm likely to add an ignore for a babelified/compiled/thirdparty directory perhaps.

How about rather than massively engineering a very simple file and encouraging blind copy+paste, you simply add the basic javascript defaults, then have a quick summary of how to encourage local ignores, and then guidelines on what things a user might add to the file, and how they might do it.

I think that way it becomes educational, hence a guideline, but also good as a basic seed for building a node project.

[yeskunall]

Working in different companies and various teams, I've noticed not many have a .gitignore_global and for that reason, I think we shouldn't fully ignore editor settings.

@vpanjganj whoops, sorry that's my bad. I didn't notice that in the existing .gitignore. Yes, agreed. Let's stick to JS projects. I was just trying to get a point across. 😊

As for major JS IDEs, Webstorm comes to mind, but I can't think of anything else. Editors however, there are many. Almost an endless list.

To ignore Node stuff, we can just do a gitignore.io/api/node. That's what I do for my personal projects.

[vpanjganj]

Hey guys, What do you think of this as a quick fix?:

### Node ###

# Logs
logs
npm-debug.log*
yarn-debug.log*
yarn-error.log*

# Optional npm cache directory
.npm

# Dependency directories
/node_modules
/jspm_packages
/bower_components

# Yarn Integrity file
.yarn-integrity

# Optional eslint cache
.eslintcache

# dotenv environment variables file
.env

#Build generated
dist/
build/


### SublimeText ###
# cache files for sublime text
*.tmlanguage.cache
*.tmPreferences.cache
*.stTheme.cache

# workspace files are user-specific
*.sublime-workspace

# project files should be checked into the repository, unless a significant
# proportion of contributors will probably not be using SublimeText
# *.sublime-project


### VisualStudioCode ###
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json

### WebStorm/IntelliJ ###
/.idea
modules.xml
*.ipr


### System Files ###
.DS_Store

# Windows thumbnail cache files
Thumbs.db
ehthumbs.db
ehthumbs_vista.db

# Folder config file
Desktop.ini

# Recycle Bin used on file shares
$RECYCLE.BIN/

# Thumbnails
._*

# Files that might appear in the root of a volume
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent

Any thought?

How about rather than massively engineering a very simple file and encouraging blind copy+paste, you simply add the basic javascript defaults, then have a quick summary of how to encourage local ignores

@antony Sounds like a good idea do you think you can come up with something?

[yeskunall]

@vpanjganj looks much, much better than the original .gitignore!

[antony]

@vpanjganj I'll have a go yeah

[MichalZalecki]

New proposal for .gitignore is definitely better but I would switch editors-specific rules for information how to add them to your .gitignore_global. There are many editors and more to come, let developers use what they want and hold them responsible for not cluttering the repo.