chore(.gitignore): Ignore composer.lock

[dacgray]

We should default ignore composer.lock.

It can contain sensitive information like gemfury keys - and so should be ignored by default.

[cyberhck]

since this is public boilerplate and our default repositories are public, ignoring a composer.lock isn't a very good idea (had this huge discussion with andre, and as you can see we're no longer ignoring composer.lock on shop). User is anyway supposed to delete the .git directory and do a init again when he starts with boilerplate. I propose, just ignore by adding to .gitignore, but don't delete it. That way we still track it, but once user removes .git and does a git init, he'll not track anymore, but if he feels like it, he can always remove from .gitignore, but for this project, we want to be able to produce reproducible builds and we want travis to go faster, so don't actually delete the lock file :slightly_smiling_face:

[dacgray]

There's still the problem of the lock file potentially containing our gemfury key. We can't expose the key on an open source repo.

This is not to say we should ignore our .lock files on other projects. Only open source projects where our key is exposed.

So since this is our package boilerplate, and a lot of those future packages will be open source we should ignore composer.lock by default.

[cyberhck]

I mean, this repo will never reference any private repo anyway, so there's no problem of exposing our keys.

When someone creates a new project either using composer create-project or git clone ..., first thing they're supposed to is to remove .git directory, (composer create-project actually doesn't clone history, it's not even a git repo at first), so all we have to do to this repo is to add composer.lock to .gitignore, and without deleting in this repo.

Once you create a new repo from this repo, it'll immediately stop tracking in your new repository (and you might even want to make it private in that case)

[dacgray]

So, this will be the default for new packages.

Can we agree that we should add composer.lock to .gitinore as a starting point for these packages by default?

[cyberhck]

I'm not sure if we understand each other.

• I don't fully agree that composer.lock to .gitignore for any package
• I agree for our private packages, that most likely will be the case (but I'm pretty sure no one except gh staff will be able to see those, or when gh is cracked and everything is public)
• for public packages (which is our default) we WILL commit .gitignore (public package shouldn't reference secret keys anyways)
• for private repository, we'll either add composer.lock to .gitignore, or rely on github being private as we're doing now.
• by default ignoring isn't very good option because our default setting for repository as announced earlier is that our repos are going to be public by default, and you'll only change something which might have business logic involved.

That's some of the point, but I'm not saying that composer.lock will be automatically tracked. We do the following:

• add composer.lock to .gitignore of this package, and commit
• that's all, and push .gitignore, that'll mean only this package will have composer.lock
• when creating new package, you've got two option, standard way is to use composer create-project, that'll NOT init git, which will mean there's a composer.lock, but also a .gitignore which automatically ignores composer.lock as soon as you do a git init.
• So ignoring composer.lock will be by default (if we want that, I'm still not sure on that one), if some package refers to our secret keys, that should be kept private anyways.
• other option to start a project would be to do a git clone git@github.com:crazyfactory/php-package-boilerplate, but when you do that, you're supposed to do a rm .git && git init && git add . && git commit -m 'WIP: initial commit' anyways, which will NOT track our composer lock,

I still think that's not a good default, our builds won't be reproducible, and we should be committing composer.lock anyways, I think keys being inside composer.lock is a bad idea already, but to overcome that, ignoring lock file isn't a good idea, instead just keep the package private.

Package can only be public if it doesn't have any secret things, (which means we'll want to commit composer.lock anyways)

Actually I'm not very good at conveying proper response via text, we can actually sit down after scrum and have a discussion what do you say? (Just read the thing and it sounds terrible, when it wasn't like that when I wrote it), actually let's just discuss this tomorrow :)

[cyberhck]

hey, actually I thought about this yesterday evening and it makes to ignore by default because this is a package, sorry for wasting your time, I forgot about that guideline somewhere it says package should ignore and app should commit.

Sorry, my bad. So we'll add to .gitignore and remove composer.lock :)