Laravel Elixir: What Else

Behat I would really like to round off the suite of testing.

Behat and Codeception would be amazing :)

First at all Codeception is a great tool would be very useful to manage with gulp.

Would be possible to 'observe' Database Schema modifications for migrations?

Source maps might be a good one (bundled with Sass)

I know it's not stricly bounded to coding but something like imagemin? Minify images is so important nowadays.

Installing hundreds of extensions may be hard, and confusing.

I think is much simpler without extensions.

Bower is a must :) See my PR here https://github.com/laravel/elixir/pull/6

Based on this:

So we're thinking about locking the core tasks, while ultimately offering a simple way to create and share your own extensions.

I think what you have already is good enough for a lot of projects.

Codeception Should be there

PHP CodeSniffer (as well as either a move to PSR or a published Laravel CodeSniffer Standard -- would be good for contributions).

Codeception +1

In my case I'd like to have the option, to add the path for my phpspec-files. Or did i miss something?

Aglio would be nice to have to document an API.

+1 for Bower with main-bower-files : https://www.npmjs.org/package/main-bower-files

Would be possible to manage composer updates with gulp watch?

I think that adding any dependency into composer.json and running gulp watch would be useful avoid running composer dumpautoload or composer update newly.

And update automatically the Providers and Facades (if needed) array of the app.php with those dependencies taking any YAML file or similar to manage the dependency, facade, and several other related items.

PHP CodeSniffer (as well as either a move to PSR or a published Laravel CodeSniffer Standard -- would be good for contributions).

I second the crap out of this one. Would be SO awesome.

Would be possible to manage composer updates with gulp watch?

Interesting thought. I don't know that my dependencies change enough where I'd have a task for this that wasn't just running ci / cu, but it is interesting nonetheless. Guess I'm saying I've already gotten as much efficiency out of that as possible through aliases.

Aglio would be nice to have to document an API.

Aglio is very cool, though since there are a bunch of tools for building API docs from Blueprint, I dunno about picking one for core. Extensions seem appropriate for this, to me.

LiveReload is a task you see in basically every Gulp, Grunt, and Guard file. It definitely is worthy of being in the core tool set of Elixir.

Support for Stylus would be nice.

What about http://www.browsersync.io ?

@JeffreyWay, I found this reference about composer updating references within gulp.

http://stackoverflow.com/questions/25057667/how-can-i-use-gulp-to-watch-for-composer-package-updates

I think this feature could be completed with the edit of the app.php file arrays (providers and facades).

PHPDoc would be nifty, but honestly that should be pretty easy to set up manually. Would you consider allowing us to submit extensions via pull request?

@Bramdevries @mdwheele Aglio is such a pain under Windows ! Last week i tried running it and lost almost whole day on Windows 8.1 x64. There is some big issues with node-gyp which add another dependency - Python 2.7.x (linux OK, Windows should be installed separately) and you should install Visual Studio Express to complete .... (which most of us will not do)

So too much dependencies for such thing to be in core :)

Imagemin, handlebars, codeception

Note: i think that there should be notice in documentation that sass is node-sass which is almost compatible with real rub-sass version 3.2 .. and latest is 3.4 so .. you know ;)

Elixir is useless without Compass support!

And Compass gives susy, breakpoint ...

@drekinov didn't know it was such a hassle, I haven't experienced those issues.

Since it is a best practice to offload static assets to a cookieless domain, it'd be nice to have a pipeline that goes all the way to Amazon S3.

Thanks, everyone! We'll talk about whether any of these should come by default.

Otherwise, I've setup a simple way to publish extensions through npm, that anyone can pull in easily.

Many thanks for your efforts @JeffreyWay.

Seems odd that the community is being asked for something that I assume would be extensible by default. Let's not forget that users can do this themselves anyways if needs be.

I'd just go with whatever works - what everyone is into now, is going to be very different in 12-24 months, so let's not get too wound up/caught up in what should and shouldn't be supported. Let's just get the basic idea out there and users can extend til their heart's content.

I would like to see a way to just simply move an array of wildcard-strings or direct files from one location to another, but also check to make sure that the files being moved either don't exist or are newer/different then the ones in my destination location. Being able to concat files directly without having them mixed into the current js or css "types" would also be very nice. I already have these working in gulp but I would like to see something in a more fluent type interface in Elixir.

These modules would allow easy manipulation of managing font files or images from bower packages quickly and efficiently. Also having the ability to "build" things like robots.txt, humans.txt, files and/or any other file that needs to be in the public folder is something I would like to explore.

I know I can just tell bower to install packages directly into public, but my goal is to have the public folder be completely built and not have to worry about extraneous files in public at all. I have bower currently installing packages to resources/assets/vendor which seems like a decent location and naming convention and I can keep the public folder as minimal as I need to.

Let me know if you guys will accept a pull request or two to enable this functionality in Elixir.

+1 for LiveReload

I haven't learned Coffeescript that much yet so I often just use plain javascript, but sometimes both in the same project and then output to one main.min.js. If that isn't possible it maybe should be?