Bower gitignore added

[geolyth]

Bower manages frameworks, libraries, assets, utilities, and rainbows installing packages in bower_components. It needs only a bower.json file and not the entire bower packages installed.

http://bower.io/

[graingert]

you need to add a trailing new line here

[reverofevil]

Why is this not merged yet? Bower is popular for years.

[geolyth]

I believe this is a useful snippet :-)

[corysimmons]

I've been going through the PR's (since Issues are closed on a GitHub project? 💯 ) and it seems like they don't want to ignore Bower.

Because............ well, I dunno...

I couldn't find a single solid argument for it. Addy Osmani talks about it https://addyosmani.com/blog/checking-in-front-end-dependencies/ and raises some good points for keeping it and not keeping it. A lot of people have raised interesting points about it, but it's all a matter of opinion whether you want to check them in or not.

Personally I make a lot of small projects where I'm the sole maintainer and don't want to check-in/out bower_components all the time.

Why allow Node to be ignored but not Bower? Both are dependency managements.

Here's a PR that's been open for months about it #1601

Another #1529

Another #904

I could go on like this forever...

So I have no idea why GitHub made this decision.

It's funny because they're letting certain projects dictate whether they let bower_components in or not... f59e22d

Luckily we have https://github.com/joeblau/gitignore.io which submodules github/gitignore, but also adds sensible customizations to it rather than trying to make this 🐴 drink.

[shiftkey]

@corysimmons

So I have no idea why GitHub made this decision.

I'm sorry that you feel like Bower has been ignored here. This is a long story, so grab a ☕ or 🍵 and read on while I try to share my experiences as the person reviewing these PRs. I don't speak for GitHub on this (although I am talking with others internally about the list that appears when creating a new repository here).

We can group the vast majority of these templates in this repository into one of three categories:

• programming languages
• command line tools
• IDEs

The reason why I group them this way relates to a couple of things:

• generally, a repository starts from choosing the language you want to start
• with teams may have a diverse range of tools and environments, and will want to compose them together as they need things
• the pace of change can vary wildly depending on the language/tool/IDE

When a contribution comes in, we want to understand the change before merging. As the maintainers, we don't have the breadth and depth of experience to know the impact of every change, and many times in the past people have returned to a PR to disagree with the change. So we try and gather more information (#1529 is actually a good example of this) for future reference.

Why allow Node to be ignored but not Bower? Both are dependency managements.

This is an excellent question. At this point I will defer to the Node.gitignore template as the canonical rule, and they choose to ignore node_modules. But it's still a hotly-debated topic question and largely depends on what sort of thing you're building with Node.

It's funny because they're letting certain projects dictate whether they let bower_components in or not...

In the context of the larger world, I don't have an opinion on this. If someone wants to submit a PR to add a rule to a certain template, I'd like to see that this decision represents a bit of a consensus from the community. That's why we ask for supporting material to understand the why of the change (for example, #1734 linked to the official front-end documentation about Bower).

but also adds sensible customizations to it rather than trying to make this 🐴 drink.

I've got all the time in the world for @joeblau who has built out something fantastic - I always enjoy where our goals overlap - and I hope we share more rather than duplicating work unnecessarily. So let's see what options we have here.

If you would like a standalone template for Bower.gitignore, I think this is better suited under Global alongside the other tools and IDEs we're tracking. For me, the things at the root of this repository should be the programming languages - as that's typically where you start when you want to write some code. Being able to layer extra things on top after - like OS, tooling or IDE templates - can still be done granularly.

If this is intended to be a thread about applying bower_modules more broadly, I guess we need to work out which templates need this - as I'm mostly working by what people propose each time it comes up.

@corysimmons let me know if that clears things up, and how we can resolve this

[corysimmons]

We can group the vast majority of these templates in this repository into one of three categories:

• programming languages
• command line tools
• IDEs

Without creating an extensive list, Drupal, Joomla, Laravel, for instance, don't fall under any of these. They're just packages you dump into a directory and then build other stuff around it (like Bower).

...

---

Actually... I spend way too much of my time arguing on GitHub. Do whatever you want with it. I don't care. I'll just keep using gitignore.io's packages.

[shiftkey]

Alright, well that didn't end up how I'd hoped. I guess this is my takeway:

If you would like a standalone template for Bower.gitignore, I think this is better suited under Global alongside the other tools and IDEs we're tracking.

I'll leave this open for a bit to see if anyone else has a differing view on this.

[shiftkey]

Also, this is missing some of the rules captured in the gitignore.io repo.

[corysimmons]

@shiftkey Yeah I'm sorry. No disrespect meant. Thank you for taking the time to write out such a thorough response. I read the whole thing. I just didn't want to get into a big conversation about this. It's nothing personal, I've honestly just been talking about stuff on GitHub for the past few days and it's really bumming me out. I want to build things - not argue with other people about how they're building their stuff.

To that end, I'm gonna try to be less of a whiny jerk (for a while anyway). 👍

[shiftkey]

@corysimmons thanks for coming back to this ❤️ - personally I've dealt with a lot of conflicts and debates over changes to PRs since becoming one of the core maintainers, so that's why I favour this conservative approach with reviews.

I do empathise with the frustration about long-running PRs, and am open to suggestions to make things easier for everyone. There's still a massive backlog of these, and I'm trying to find spare cycles to work through these on top of everything else I look after.

My contact details are over on my GitHub profile if you'd like to follow up about this privately.

[reverofevil]

@shiftkey I'm afraid the process of using this repository is not in any way similar to what you've described. People just google for something like "Intellij IDEA gitignore" or "node.js gitignore" and then put what they find into their .gitignore files. They don't classify these searches in any way like "Intellij IDEA IDE gitignore" or "node.js language gitignore". That's why the current structure with "Global" folder is misleading: nobody understands what it is at the first sight. They don't even care.

People most likely search for what they should delete. You don't see npm logs every day if you're programming in Node.js. It's easy to forget about these. That's why .gitignore files in this repo usually comment what it is. There's a rule to delete .mod Fortran module files in C++.gitignore. It can delete some music files, if one is writing something like a 64k intro in C++. Why is that line there? It's just easier to delete such rules when you see them than to write them by memory.

That's why bower.gitignore should've been included long time ago. You need no philosophy to push into a key-value store something people will have to read anyway.

As you probably have mentioned, people don't like spending time arguing on github instead of programming. When you become too opinionated to maintain a previously awesome repo, people just make a fork or use it as submodule.

[corysimmons]

so that's why I favour this conservative approach with reviews.

Conservative is fine. Closing several PRs over the years without a good explanation isn't that.

I do empathise with the frustration about long-running PRs, and am open to suggestions to make things easier for everyone.

Again, I think if it's something so common that there have been several different users go through the hassle of tracking down this repo, forking it, cloning it, adding the ignore, and submitting a PR, then it's probably worth merging, or at least taking a very close look at it.

My contact details are over on my GitHub profile if you'd like to follow up about this privately.

Nah that's cool, unless you just wanna be friends?
http://www.cc.com/video-clips/e8lt1x/nathan-for-you-scientifically-proven-fun

[shiftkey]

@polkovnikov-ph @corysimmons thanks for the feedback.

That's why the current structure with "Global" folder is misleading: nobody understands what it is at the first sight. They don't even care.

Agreed. I'm still trying to find that right balance here between structure and chaos, and that Global name is something I'd like to change.

There's a rule to delete .mod Fortran module files in C++.gitignore. It can delete some music files, if one is writing something like a 64k intro in C++. Why is that line there?

This is exactly the sort of pain I get to deal with during reviews, and I feel terrible that I don't have an understanding of this example from looking at #1142 where it was merged in. My current process isn't without flaw either - for example, I thought #1815 was a reasonable change but it turns out to break scenarios for some users, which I found out later.

Having that context around rule additions or changes is something I want to continue to push for.

Closing several PRs over the years without a good explanation isn't that.

This is something I'm actively trying to improve, and will continue to do as I triage the backlog of outstanding PRs.

Again, I think if it's something so common that there have been several different users go through the hassle of tracking down this repo, forking it, cloning it, adding the ignore, and submitting a PR, then it's probably worth merging, or at least taking a very close look at it.

Agreed. For the standalone Bower.gitignore, the last time this came up was in 2013 - and there was a discussion around it before it was closed by the author.

For things that are not as mainstream, it's hard to gauge interest in formalizing templates. I have ideas to improve this, but want to flesh these out and gather feedback before adopting them.

[barraponto]

I believe, all things considered, Bower.gitignore belongs to the global namespace.
It is opt-in by default, so it should have no effect for those users.
As for the other .gitignore files that currently ignore bower_components (such as Rails.gitignore), they should be cleaned up, making ignoring bower stuff definitely opt-in.

[shiftkey]

I merged in #2157 as lots of people have proposed adding it to the Node.gitignore file.

Please open a new PR if you think something needs to exist under the Global namespace.