Including grunt-build-control

[CodisRedding]

Would this project benefit from grunt-build-control? Seems like a good fit.

[DaftMonk]

Yep, I'm planning on it. Need this PR to get accepted first robwierzbowski/grunt-build-control#25

[CodisRedding]

Awesome.

[ghelton]

Awesome! This is the first thing I add each time I generate a project.

[JaKXz]

@DaftMonk why don't we just use your fork for now? There are no [major] upstream changes anyway.

[DaftMonk]

@JaKXz We could do that. I'll probably need to publish the package on npm under another name so that we can reliably use it.

[meeDamian]

How about Github notation? Works like this:

{
  "dependencies": {
    "grunt-build-control": "DaftMonk/grunt-build-control"
  }
}

[JaKXz]

That's exactly what I was thinking Damian.

[DaftMonk]

@chester1000 I could do that, but it would be less reliable because if the forked repo ever changed, then it wouldn't be referencing the correct version.

[meeDamian]

I believe it will always default to the current state of a master branch. We, most likely, won't be able to use legacy versions, but newest one should work as expected.

[meeDamian]

Unless you mean upstream repo, then we would have to keep track of it, and merge (at least with every change that's relevant to us).

[DaftMonk]

The problem is that theres no guarantee that the github version will exist 6 months from now, or that it will be exactly the same as it is today. For example, if I changed my github username it would no longer be a valid dependency, or if I merged changes from upstream, it may just suddenly change the way it was working for people who use it in their projects. So by its nature, it would be an unstable dependency.

[meeDamian]

@DaftMonk If you changed your username some random dependency would be least of anyone's problems ;).

AFAIK using forks is a common practice when dealing with problems with external PR's. Also, including DO-NOT-USE-THIS-FORK-type-of-disclosure on top of README file would help with that as well. And, if you consider changing your username, maybe migrating generator-angular-fullstack (with all dependencies) to an organisation is a good idea?

[DaftMonk]

@chester1000 Good point about organizations. With that in mind, I may just use the fork directly.

Though I should probably put my changes into a branch.

[meeDamian]

@DaftMonk I'm not sure if notation like DaftMonk/grunt-build-control#other-branch works and, to be honest, I really don't see the point of it. If you create organisation first and then press fork button, GitHub will ask you for which account you'd like to create a fork for. And then Github will properly mark this repo as a fork. And IMO that's more than enough. But if you want to make it 99.9999% foolproof you can also include README disclaimer (not sure if it won't be an additional hassle with upstream merges, though).

[DaftMonk]

Closing with 4485223