Comments 31
Странно, что выпустили сейчас, мне он кажется сырым: сразу заметна неоднородность наименований классов (часть с неймспейсами, часть без) и очень поверхностная надстройка elixir над gulp, которая без расширения способна выполнять только самые простые задачи.
Плюс этот elixir сильно повышает планку навыков JavaScript, необходимых для использования фреймворка.
Попробуйте простой пример: объединение нескольких less, sass и css файлов в один.
сразу заметна неоднородность наименований классов (часть с неймспейсами, часть без)

можно пример подобных классов?
Например, ./database без неймспейсов. Или ./tests.
Понятно, что мелочи, но все равно неаккуратно и вводит в заблуждение.
Думаю, OnYourLips имел ввиду папку database, где лежат seeds и migrations. Но я бы не стал так категорично сетовать на неоднородность. Если говорить об однородности приложения, то тут все в порядке, а вышеупомянутые классы ничто иное как хелперы и на функциональность приложения никак не влияют и в общем-то не должны знать о приложении в принципе.

В Laravel 4 действительно была мешанина автозагрузки, но теперь все довольно лаконично:
"autoload": {
    "classmap": [
        "database"
    ],
    "psr-4": {
        "App\\": "app/"
    }
},


По поводу вашей задачи для эликсира:
elixir(function(mix) {
    // сохраняем в css ресурсы
    mix.less('app.less', 'resources/css');
});

elixir(function (mix) {
    mix.styles([        
        // скомпилированный app.less и чистый page.css
        "app.css",
        "page.css"
    ], 'public/css/everything.css');
});
// объединенный файл с less и обычными стилями будет лежать тут public/css/everything.css

Добавить к этому примеру sass не составит труда

UPD: извините, ушел в магазин, когда начал писать ответ. Продолжил, когда вернулся, а вы уже ответили
Пробежал глазами заголовок, и прочел «Доигрались, релиз Laravel 5».
Ого, думаю, это ж чем так опасен 5й Laravel?

Надо больше спать.
Господа, подскажите годную инструкцию по установке homestead для laravel 5 под windows 7.
примерная инструкция:
— ставите virtualbox
— ставите vagrant
— пишете vagrant up в папке проекта
Кто-нибудь в курсе как в новую версию вписывается разработка собственных пакетов? Раньше можно было мучать workbench. Я верно понял что его «выпилили» и предлагают новые пакеты устанавливать через composer?
С одной стороны, конечно, здорово. С другой — доставляет определённое неудобство.

К примеру сейчас я веду работу над двумя пакетами. Одни использует в качестве зависимости второй. Получается что после того как я внёс изменения в пакет, то мне нужно закоммитить эти изменения и выполнить composer update в другом пакете.

Можно, конечно, использовать симлинки, но это как-то… неправильно, что ли.
У меня так и сделано, вроде.

{
    "name": "inikulin/nourriture",
    "require": {
        "inikulin/gluten": "*"
    },
    "autoload": {
        "psr-4": {
            "Nourriture\\": "src/"
        }
    },
    "repositories": [
        {
           "type": "vcs",
           "url": "/Users/inikulin/gluten"
        }
     ],
    "minimum-stability": "dev"
}


И получается, что бы в проекте inikulin/nourriture получить изменения, которые были сделаны в inikulin/gluten мне нужно сначала закоммитить и только после этого они подтягиваются композером.

По ссылке что вы дали автор пишет что можно сделать симлинк на репозиторий. Но этот метод, я так понимаю, в Windows не работает.
Что вам мешает использовать симлинки в виндовс? Если только вы не на Windows XP или ниже.

Символическая ссылка (symbolic links) — доступна с Windows Vista. en.wikipedia.org/wiki/NTFS_symbolic_link

Но все равно эта все похоже на костыль. Для локальной разработки библиотек надо строить дев окружение, а все остальные участники должны забирать обновления из удаленных репозиториев. Если вам хочется подключать локальные библиотеки, то надо или допилить автолоадер или иметь разные composer.json для вашего локального окружения и для продакшена. Тогда в локальном composer.json можно указать локальные пути библиотек для автолоадера. А в ide их добавить как внешние библиотеки.
Мешает как раз то что это костыль.

Кстати, раз вы упомянули разные composer.json в зависимости от окржужения. Есть какой-нибудь рецепт как это организовать? Исключать сам composer.json и вместо него коммитить некий composer.json.dist?
Я бы попробовал сделать трюк с автолоадером, и перезаписывать пути к папкам в локальной версии приложения. Вот как тут stackoverflow.com/questions/28106850/how-to-use-composer-to-load-php-classes-from-local-repository и просто подключать локальный файл с доп правилами если есть. Или пойти глубже и написать плагин (или хук) для композера который будет зависеть от какого нибудь local_composer.json =)
Но этот метод, я так понимаю, в Windows не работает.

Если вы используете например Vagrant, то это не проблема.
Напрягает немного, что заинтерфейсили почти всё, а Eloquent, QueryBuilder технично обошли стороной.
Тоже заметил, отсутствие возможности внедрять зависимости для моделей немного печалит.
Модель стоит довольно обособленно от всего остального, поэтому и внедрять туда все подряд не было бы лучшим подходом. Вы можете создать репозиторий для модели и внедрять туда что душе будет угодно
Это костыль, и не работает в большинстве случаев (допустим если надо внедрить acl). Если уж собрались поддерживать философию IoC то надо поддерживать, а нет так, на пол шишечки.
В каком плане безопасно? Например, Jeffrey Way перевел Laracasts на 5ую версию за вечер и был весьма рад этому событию :)
Only those users with full accounts are able to leave comments. Log in, please.