Refactor project into a more useful seed

[lookfirst]

Right now, to use this project, you have to clone it and then rip out the parts you don't need. You also have to come up with a good understanding of how all the parts fit together and how the gulpfile interacts with them. Sure, it is pretty small (right now), but it is kind of intimidating for a new user. This project isn't the only one with this issue, all seed projects kind of suck in this same way.

I've been thinking about this a lot. There is other projects like Yeoman, which give you the Rails type experience of being able to 'new' a project with a generator model and create templates for things like controllers, etc. This is great for just starting off, but doesn't solve the issue of when the base project changes, updating your own project, most of that code lives in the gulpfile.

Sorry this is so long winded.

What I was thinking as a first step to providing a better experience would be to extract out all of the gulp tasks that do stuff into functions and put them into their own npm module. This way, the gulpfile just loads a bunch of functions that can be more easily re-used (and therefore updated). The seed gulpfile will then just look like a bunch of method calls that setup the tasks.

Once we have that, I think that building a yeoman experience might be the next step. Then we won't have to rip out all the existing example code as yeoman can generate that for us.

Thoughts?

[amcdnl]

We have a blog article we are going to do soon which will help with this. I also know that @ocombe is doing a talk on this so maybe he will post that for us too.

Agreed with the gulp comment, I just saw this being done for the first time the other day and was anxious to integrate here.

[lookfirst]

Where did you see it done?

The angular 2 gulpfile (tools/build/*) is what got me thinking about it.

[amcdnl]

Here we go: https://github.com/greypants/gulp-starter/tree/master/gulp/tasks

[lookfirst]

:+1: (i even like the one you had in your pre-edited comment)

[amcdnl]

Ya both are good, that one wasn't gulp per say just one off scripts which is why i switched to that one.

[lookfirst]

Ok, I've taken a stab at this and so far I'm pretty happy with the initial result. It can certainly get better, but it is a good first pass. It is called gulp-helpers. You can see an example of a full working gulpfile in my seed project. As you can see, the file is now mostly just configuration and very little code. Sure makes working with seed projects as a basis now so much easier.

gulp-helpers is written in ES6 too. Seemed like a good way to start to get my hands dirty with it.

Enjoy. =)

[amcdnl]

I like your update, wanna un-coffee ;) it and do a PR?

[amcdnl]

reference @lookfirst gulp file: https://github.com/lookfirst/systemjs-seed/blob/master/gulpfile.js ...

[brianfeister]

For what it's worth, I'm joining this project (using it for a huge, just-now-starting-development production app) from a previous seed of https://github.com/DaftMonk/generator-angular-fullstack. Personally, I would love to see this project move in that direction. For me, I had to refactor it all to accommodate my Node backend living in the same project root. One nice thing about generator-angular-fullstack is that it doesn't force it's opinions on you, so you just run the generator and and choose if you want a Node backend or not and then the generated code (from the yeoman generator) accommodates your choice. I don't think we should bother with supporting every configuration under the sun, but if the project became a yeoman generator, then the burden could be placed on individuals wanting ____ (tech thing) to PR that and it would not hurt those who don't want to use (LESS, SASS, CoffeeScript, Node Backend).

[lookfirst]

@brianfeister you may want to look at what i've done with this project. i've got a generator started too.

[lookfirst]

today, i'm going to split out the routing.js file into its own project. that is the last thing that is really specific.

[ocombe]

Until we can remove it totally :)

[lookfirst]

@ocombe Hurry up! ;-)

[brianfeister]

Are you separating your front and backend @lookfirst ? Also, make sure to steal liberally from https://github.com/DaftMonk/generator-angular-fullstack/blob/master/app/index.js for examples of giving users prompts in yeoman like "Do you want a Node backend?" and "Do you want to use React?"

[brianfeister]

Also, have a look at https://github.com/Swimlane/systemjs-route-bundler/issues/15 for a problem I ran into when migrating the JS into /client/src rather than project root

[lookfirst]

@brianfeister I see this as a strictly frontend project. I see the future as being that the frontend and backend are really two different beasts communicating through JSON. (Don't forget about my other project JSOG).

If you want to throw everything into a client and server folder, that's up to you, but I think they should have separate build processes.

In terms of using React (ngReact) or not, that is just a) a dependency in your package.json / system.config.js b) it doesn't affect anything. The fewer questions we have to ask, the easier everything is.

[amcdnl]

+1 to hurry up @ocombe ;)

[ocombe]

:D According to my plans, I should get v1.0 out this week, then I'll start working on 1.1 that should be finished by the end of the month. After that it's 1.2 with the plugins for SystemJS & Webpack.

[amcdnl]

@ocombe I see webpack getting a lot of attention. Why would you choose that over System since System is ES6.

[ocombe]

Because of jspm ?

[ocombe]

Wait, you're asking why someone would choose webpack instead of systemjs ?

[lookfirst]

I'm seriously not a fan of webpack. I tried it and found it to be a giant mess with terrible documentation. SystemJS + SystemJS builder is the future.

[ocombe]

Well I've watched the videos on egghead.io by @kentcdodds and it looks freakingly cool :) It's really smart about the module building part and will optimize the bundles so that you will load the minimum number of files (instead of one file per resource like it is the case with systemjs). And you can use ES6 with Webpack as well.

[ocombe]

Also a lot of people that I know recommended webpack to me, and they are really good at what they do, so I'm inclined to trust their judgment. I haven't tried it myself yet, but I'm willing to give it a chance.

[kentcdodds]

Great to hear @ocombe! :D

[ocombe]

By the way @kentcdodds, why do you use require instead of import in your videos with webpack? Since your code is transpiled by babel, it should work, right?

[kentcdodds]

@ocombe, yes, I use them interchangeably actually... Weird. I should probably just conform to the ES6 style I think... Haha.

[amcdnl]

@ocombe I gave it a stab but had no luck. I've got some articles of @kentcdodds to go through after we chatted at ngconf.

@ocombe I wrote a bundle system that utilizes systemjs's build system to do that kind of bundling, is that similar to what webpack is doing?

[lookfirst]

@ocombe I found this idea by @amcdnl and his team to be more in line with what I'd want to see... route based bundling! https://github.com/Swimlane/systemjs-route-bundler

[lookfirst]

1. git clone https://github.com/lookfirst/systemjs-seed.git
2. npm install
3. SITUATION=production gulp run
4. http://localhost:9000/todo
5. http://localhost:9000/react

Now, look at what is loaded by the browser when you visit those urls. =)

[ocombe]

Anyway it doesn't really change what I'll be working on, which is a hook on require to register angular components when their files are loaded. Since require is used both by systemjs & webpack, and pure ES6 code transpiled to ES5 by babel, it should work! :)

[amcdnl]

@ocombe ya, I think thats the most painful thing at the moment. having to re-write the modules is the most annoying thing ever - http://www.screencast.com/t/VWonfVKNcp

[ocombe]

well, get used to it because you'll probably use it more and more :) Unless we can imagine a tool that would add the import in your files at build time

[lookfirst]

if you use my version of ng-html2js, you get the strings for you...

import fooTpl from './views/foo.tpl'
angular.module(module.id, [fooTpl.name])

(note the use of module.id too!)

[amcdnl]

@ocombe no I was meaning having to write the import and then declare the dependency in the angular module.

@lookfirst ya, I'm about to try that out! Wish @marklagendijk would accept your PR though! Whats that module.id thing too? I haven't seen that....

[ocombe]

Ah yes, @kentcdodds has a trick for that, see https://github.com/kentcdodds/webpack-angular/blob/master/app/kcdModule/index.js All you need is to export the name of your module in each file

[amcdnl]

@ocombe you can't nest ES6 module syntax like that though. :(

[ocombe]

yes, it only works with require :)

[kentcdodds]

@ocombe that's the reason that I sometimes mix es6 and require

[amcdnl]

@ocombe @kentcdodds Ya, I had to do that here: https://github.com/Swimlane/angular-systemjs-seed/blob/master/src/common/utils/routing.js#L13 with system. I hate it. I don't have a problem doing it in one place but all over my app might drive me batty!

[lookfirst]

@kentcdodds I'd like to see how you mix require with es6 and writing unit tests. ;-)

[kentcdodds]

Writing unit tests with ES6 is actually quite awesome. Man I wish I had time to do all the egghead.io lessons I could think of!