Port from yeoman to lineman

[bkeepers]

Yeoman was the easiest thing to get started with, but I've never really been a fan of it. It's just too bloated. This ports the app over to using lineman. As part of that, I also switched the CSS from sass+compass to stylus+nib.

/cc @searls

TODO

• get octicons working
• script/bootstrap
• script/server
• enforce SSL
• Deploy to heroku

[bkeepers]

@searls I have this ported to lineman and everything is working wonderfully in development. I'm having an issue with deployment and I would love your thoughts.

Since this app deals with a GitHub auth token, I want to force SSL in production. I moved some code I was using in yeoman over to config/server.js (d0cb331), but the problem is obviously that a node server does not get run in production. How would you force SSL?

I've also been thinking ahead to #1 and will probably need a very small server component to handle the OAuth dance. I know Lineman is predicated on a separation of frontend and backend (which I have enormous respect for). However, it feels odd to have to create a separate app just to handle client authentication. In this case, I would argue that OAuth is actually a concern of the client application and should be included in the same code base. Any thoughts or advice on handling this?

[searls]

There is a minor blind spot in the tools we have built so far. Given these three usages:

1. Purely static site with no backed or a backend on parse.com or Firebase
2. Very light server side needs that don't warrant another app or deployment story
3. A server side app exists with its own deployment process that can sort of Hoover up the lineman app's dist directory and drop it in the right place to be available for clients. 

We handle 1 & 3 quite well, but don't have enough experience with 2. This may be an opportunity for us to make lineman better.

I will say @theotherzach has done some work on an additional heroku build pack for apps with a ruby backend as well-- https://github.com/testdouble/heroku-buildpack-lineman-ruby

On Sun, Nov 10, 2013 at 5:50 AM, Brandon Keepers notifications@github.com
wrote:

@searls I have this ported to lineman and everything is working wonderfully in development. I'm having an issue with deployment and I would love your thoughts.
Since this app deals with a GitHub auth token, I want to force SSL in production. I moved some code I was using in yeoman over to config/server.js (d0cb331), but the problem is obviously that a node server does not get run in production. How would you force SSL?

I've also been thinking ahead to #1 and will probably need a very small server component to handle the OAuth dance. I know Lineman is predicated on a separation of frontend and backend (which I have enormous respect for). However, it feels odd to have to create a separate app just to handle client authentication. In this case, I would argue that OAuth is actually a concern of the client application and should be included in the same code base. Any thoughts or advice on handling this?

Reply to this email directly or view it on GitHub:
#21 (comment)

[searls]

Thought a little more about this on the plane last night and I'm still a little torn on the best approach.

As it is, one of the most commonly requested features is "let me put my dev/stub express server into production", which is of course not a good idea, but indicates that there's an untapped need.

Hmm.

Also, in my email reply above, this got quoted away:

I will say @theotherzach has done some work on an additional heroku build pack for apps with a ruby backend as well-- https://github.com/testdouble/heroku-buildpack-lineman-ruby

[bkeepers]

I tried solving the problem myself by providing my own Procfile that runs a node server that serves the app and static assets, but it appears that the node runtime is not available after the compile process?

I think it would be ideal if the buildpack supported both dev and runtime dependencies. Lineman should be listed in devDependencies. By default it could still compile the assets and serve them statically with apache. But, you could provide their own Procfile that would just work the same as Heroku's default node buildpack.

Thoughts?

Related, I just went to look up devDependencies in the package.json docs and came across:

Please do not put test harnesses or transpilers in your dependencies hash.

[searls]

Are you feeling blocked on this? Not sure what I can best do to help

On Mon, Nov 11, 2013 at 10:36 AM, Brandon Keepers
notifications@github.comwrote:

I tried solving the problem myself by providing my own Procfile that runs
a node server that serves the app and static assets, but it appears that
the node runtime is not available after the compile process?

I think it would be ideal if the buildpack supported both dev and runtime
dependencies. Lineman should be listed in devDependencieshttps://npmjs.org/doc/json.html#devDependencies.
By default it could still compile the assets and serve them statically with
apache. But, you could provide their own Procfile that would just work
the same as Heroku's default node buildpack.

Thoughts?

Related, I just went to look up devDependencies in the package.json docs
and came across:

Please do not put test harnesses or transpilers in your dependencies hash.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/21#issuecomment-28209529
.

[bkeepers]

@searls a little, but certainly not by you. I'll look into modifying the buildpack.

[theotherzach]

Given the ruby buildpack is designed for the typical heroku ruby deploys where our lineman one is designed for static sites and we would like to support more non-static deploy stories...

It would be nice to extract the lineman build and file move steps out of individual forked buildpacks and into something that we could re-use. Here is what needs to happen at deploy:

• pull down node and npm if needed
• pull down and install ruby deps if using sass and if needed (not implemented in ruby build pack)
• retrieve node_modules from cache if it exists
• npm install
• cache node_modules
• lineman clean && lineman build
• move assets into the expected location

https://github.com/testdouble/heroku-buildpack-lineman-ruby/blob/master/bin/compile

I'm not thinking of many great ways to generalize this off the top of my head. We may just need to reinvent the wheel each time somebody gets interested in a new platform.

[bkeepers]

I'm not thinking of many great ways to generalize this off the top of my head. We may just need to reinvent the wheel each time somebody gets interested in a new platform.

Git submodules suck, but maybe the lineman components could be pulled out into a submodule?

[searls]

🎆