[suggestion] Build and deployment pipeline should be a separate repo.

[trusktr]

The readme says

What ngus Needs:

• Build and deployment pipeline via Gulp or Browserify.

My suggestion would be to not couple the library to any particular build system, and make ngus as build-system agnostic as possible. Back in the Famous 0.3.x days, I had started making a library of components with Famous. I made it work in various build systems (see the package.json scripts) and I put some instructions in the README for each of the most common build systems.

Although my library is outdated (I will continue with the new Famous Engine soon! 😄 ) it's concept of being build-system agnostic is still good.

Important things to note:

• My library contains only that: my library. No examples, no screenshots, no etc. This makes it easy for people to consume your library straight from GitHub, Some package managers and bundlers like JSPM and bower, allow for dependencies to come straight from GitHub. So keeping the library strictly a library helps make it more consumable. Examples and extras can be placed in a separate repo. A repo called ngus-seed could contain your preferred build system and that can be a starting point for some people.
• Libraries shouldn't be bundled in the repo. ngus has both Famous 0.6 and 0.7 stored in the repo. There's other stuff like angular2.dev.js, traceur, etc. Those shouldn't be kept in this repo. Some people will use their own setups to get those dependencies (for example, people who use Webpack+NPM).
• Distribute both the original source and the compiled source. For example, my library's source code is in the src folder. Users of JSPM and Webpack can, for example, specify that src is the root of the library, and they can use those original files in their project and handle compile steps themselves. The prepublish script compiles everything from src into the root of the project right before it gets uploaded to npmjs.com. The compiled files are in CommonJS format instead of ES6, ready for consumption. The other build scripts (build-amd, etc) are there in case someone wants a different module type for whatever reason (f.e. someone using RequireJS can make AMD modules for their project).

For the most part, what you've got here in the ngus repo is actually what can be called ngus-seed. What you can do is copy this repo to one called ngus-seed, then in this repo store just the ngus library. I'm working on react-famous right now, and you'll see that I've made a pull request (work in progress) to do a similar thing to react-famous. Forthcoming I'll update the README with basic instructions for each build system. I find that instructions for Browserify, Webpack, and other similar tools are enough, and that people who want to use Gulp or Grunt know enough from that info to configure their Grunt or Gulp.

I am happy to contribute this idea since I like your project. Cheers. 😃

[steveblue]

@trusktr I like your methodology for sure. Traceur and system are bundled temporarily to avoid problems from outages on JSPM, which have been happening as of late and I agree, the repo is kinda messy right now, not ideal or dynamic based on user needs. Really all this repo should do is house ngus library with possibly a compiled version for distribution and like you said, another repo can handle the build / deployment pipeline for seeding an ngus project and then possibly a third repo that is an app which builds off the seed repo and has examples in it. I will create ngus-seed repo and make you a contributor.

[steveblue]

@trusktr part 1 of this task has been completed in v0.0.2. I'm going to fork an existing Angular 2.0 seed project and integrate one of the packages in the /dist folder so there is at least a working example available. Later, I will update the build tools in this repo to also output minified versions, but we are a long way off from that. Priority is to build out the integration between Angular 2.0 and Famo.us 0.5+

[steveblue]

The new seed repo for ngus is at https://github.com/steveblue/ngus-seed