Consider using grunt-build-control

[thorn0]

This Grunt task can be utilized to keep built files and docs in separate branches. It will be easier to track changes in the sources and use branches for development as commits won't be bloated with irrelevant information.

If interesting I can try making a pull request for this.

[jeme]

I have only briefly looked at it, so can't quite comment on weather or not it fits into something I have wanted to do for a while.

Basically I like having everything related to the project in a single repo, so it has a single source... But I have looked at using https://github.com/tschaub/grunt-gh-pages to build and push the documentation automatically to the gh-pages branch on successful builds on the main branch. (We don't wan't pull-requests to suddenly push their changes before merged)

If that solves the same problem then it would be greatly appreciated.

[thorn0]

So my proposal is to not keep the following things in the master branch:

• Resulting built files. They go to a separate branch, say build. Commits in this branch would be tagged with release tags, so Bower would use them.
• Documentation and site. They go to the gh-pages branch.
• Individual js-files compiled from ts-files (build/src/**/*.js, like build\src\directives\jemLink.js). They're not needed to be kept in the repo at all. Also there are a lot of unused .d.ts-files in src.

In the end, we'd have the clean master branch, commits to which would only contain changes to the source files (*.ts mostly). When you need to publish a build, you'd run grunt buildcontrol. It would create commits in build and gh-pages, which you'd then push to GitHub (with a tag if you need to mark this build as a release). Does this sound good?

[jeme]

I don't agree fully.

1 & 3 ) It is possible to move resulting build files into a separate branch, I went for an entirely separate repository with https://github.com/dotJEM/angular-tree (https://github.com/dotJEM/angular-tree-bower), which is the same thing the angular core team does... I don't know which approach is best as I am only familiar with one of them, it could give separation to the 2 modules (main and legacy) but I don't think we will hold on to the legacy module anymore which would remove the advantage there. But I agree that in the long run the entire build folder should be removed from the main branch, for now it has just been convenient.

But something has to be done, because I my self is very tired of getting all the source when pulling it down with bower, it also gives me problems when deploying to KUDU as it tries to pick up on the .sln files etc... So I would like something to be done.

2. As for the docs though, i completely disagree there, first of, you should not have to change branch to work on the docs for the repository, secondly you have to think of the gh-pages folder as the source of the docs and not the actual docs... In the long run things like concatenation and minification etc should be applied to the docs as well before they are deployed to the gh-pages branch... Could rename the folder to "docs" to remove confusion though...

1 & 3) I am actually thinking of throwing TypeScript out completely, the reason for the "redundant" files is actually because I had issues with the VS plugin at some point when writing tests, so adding those solved that... But I have given up on using TS on every other projects I have created since so it may as well be a move to begin to rewrite the source in pure JS. Everything in build except for the files in the root can ofc easily be ignored, that is just pure slack from my part that I have not done that.

[jeme]

There is also allot of files in the root that should be moved I think, e.g. karma configs etc... and then there is probably loads of build modules we could update...

[thorn0]

As for the docs, I'm not saying we would need to switch branches manually. There are two kinds of the files that consist the docs: generated and non-generated. So the generated ones shouldn't be in master. And its the grunt script that would commit them to the gh-pages branch. Just like it would do it with the build branch. And of course that part of the docs-related files that isn't generated should be kept in master.

As for TypeScript, I think it would be interesting to continue this experiment, especially now that TypeScript 1.1 is out.

[jeme]

I can agree on that, the only generated part of the docs as of now is some of what is under gh-pages/docs which is the output from ng-docs (so API documentation)... Which makes it a bit problematic, however this is something we can restructure our way out of... So it may be desirable to putting down a "docs" structure before making any changes.

E.g.
gh-pages\* -> docs\*
gh-pages\docs -> docs\api for generated files, then move the images out of there maybe...

doc is obsolete, ng-docs uses a temp folder instead.
samples are obsolete as well, they are moved into "gh-pages" as samples that can be posted directly to plunker.