автоматизация рутины
 

Рассказ о том как я избавляюсь он некоторого колличества рутинной работы. Хотелось бы услышать кто что думает? Может кто то знает более красивые решения? Вообще занимается кто нибудь подобной ерундой? Я относительно недавно к этому пришёл.


Структура каталога js-скриптов:
- Принцип именования файлов только для наглядности, его задача - показать, что все файлы которые в последствии будут сшиты в "script_1.min.js" находятся в папке "script_1".
- Также в папке "js" лежит файл "javascript.php". Он подключает скрипты на страницу. Либо "исходники", либо сжатые файлы, в зависимости от $_SERVER['HTTP_HOST'];. В "javascript.php" дял каждого файла определён массив вида: array('version' => 'x.xx', 'pages' => array('xxx', 'yyy')), где version - версия скрипта, pages - разделы сайта к которым скрипт подключается. На сервере настроено кеширование (заголовки Expires , Cache-Control).
- Сжатие скриптов производится Google Closure Compiler'ом. Есть скрипт генерирующий инструкци для командной строки запускающие сжатие скриптов.
- Папки script_1, script_2, ... script_n добавлены в список исключений в настройках развёртывания WebStorm.


Итого (как всё происходит):
1. Пишем код добавляя/удаляя файлы в папках script_x. Заботиться о подключении не нужно, всё настраивается один раз. Сами файлы script_1.min.js у меня достаточно большие, поэтому очень удобно в процессе разработки разбивать их на более мелкие фрагменты.
2. Правим значение version дял изменённых файлов и сжимаем файлы.
3. Заливаем папку "js" на сервер. Благодаря настройкам развёртывания зальются только сжатые скрипты и файл "javascript.php".

В таких моделях возникает проблема слежения за зависимостями между файлами.

Допустим понадобился вам script1.js, подключили к проекту, а он, оказывается, требует себе script2.js. Ну без проблем, подключили script2.js, всё работает. Через пол-года script1.js по каким-то причинам стал не нужен, но его зависимости уже никто не помнит. script1.js исключаем из проекта, script2.js продолжает там болтаться мёртвым грузом.

Второй случай: миграция скриптов между проектами. Проектами в узком смысле этого слова, просто между страницами одного проекта. Подключаем скрипт с другой страницы, а он, оказывается, хочет ещё один оттуда же, а тот в свою очередь ещё парочку. Подключаем скрипты один за другим, попутно разрешая возникающие конфликты. И вместо того, чтобы писать код, пол дня ушло на подключение своих же скриптов в свой же проект, но на другую страницу.

Я предпочитаю, когда в каждом файле указаны его зависимости. У меня это выглядит, как серия комментариев //#include script.js в начале файла. В результате нужно думать, только какие функции из какого файла нужны в текущем файле, а подключаемые файлы свои зависимости сами привезут.

у меня чуть по-другому :
в папке scripts - все скрипты. далее, в ней находятся папки с скриптами (частные имена), а в них - разбитые по смысле файлы, которые воедино собранные, составляют сам скрипт.

процесс сборки: где-нибудь лежит Makefile (ещё не определился с его местонахожденим, но пока в каждой папке скрипта он лежит), который собирает скрипт и "компилирует", т.е. обрабатывает его в GCC в обычном\advanced режиме.

пример Makefile :
в будущем буду добаратывать этот способ сборки файлов :) да и сам Makefile коряв, я знаю. писался на скорую руку.

пишу в Vim, там сборка под рукой :
когда вношу изменения в файл, ввожу две команды
хочу это соединить в одну, но пока до прочтения манов тоже руки не доходят

Сборка должна быть не под рукой, а на лету при разработке :)

она будет на лету, будучи включенной в команду сохранения )

Ну я занимался. Там ещё не всё сделано, но твою логику сборки можно настроить без проблем.

B~Vladi,
Было в закладках уже. Видимо встречал тему на форуме, но забыл. Времени как то всё нет. А эта штука под виндой запустится?

melky,
Make-файлы и vim это не для меня. У меня стоит убунта свежая, я там даже апач настроил полностью, но привыкнуть не могу не как. Месяца 2 уже не запускал её. Если бы не было семёрки я бы точно на линукс перебрался, а так пока нет.

Kolyaj,
С инклудами хорошая идея, возьму на вооружение. Правда у меня пока не на столько всё сложно.

Да, это полностью кроссплатформенно. Я позже ещё займусь им, можем вместе развивать.

Наш кэп,
ну то есть при разработке то, что понаписал, запускать необязательно? Ну так, ради интереса, работает ли.

а я легко смог перебраться, т.к. с нуля "настраивал линупс", и сделал всё, как мне удобно. правда, время на это потратил... но у меня оно есть. Makefile легко заменяется на BATCH.

тут ещё зависит кое-что другое... вы в чём код пишете?

я раньше любил notepad++ и не любил IDE'шки. но в нём мне не хватало навигатора по коду, что я с лёгкостью сделал в виме. в принципе, последний у меня превращён в notepad++ на линуксе.

та же история. сейчас notepad++ использую только для php. всё остальной в WebStorm

А если процесс сборки будет занимать много времени? GCC не такой уж и быстрый.
Не лучше ли разделить на dev и prod-режимы?

GCC нормальный, это java запускается не быстро, обычно из-за антивируса. Но это всё неважно, т.к. при разработке gcc не нужен, сжимать файлы нужно только при выкладке, на лету нужно только собирать.

Ну дык в процитированном тобой сообщении есть фраза "при разработке".

А, я подумал делать полную сборку при разработке.

Я много размышлял на эту тему. Как вам такая схема.
К примеру, у нас 1 файл разбит на несколько для удобства. В сборщике указываем нужные файлы, которые будут соединены в файл fileName.js. Пример, как бы это выглядело в моем сборщике:

{ // Конфиг модуля JSCompressor
  'lib.js': { // Некая абстрактная либа
    'includes': 'lib/*'
  }
  'fileName.js': {
    'includes': ['fileName/file1.js', 'fileName/file2.js']
    'depends': ['lib.js'] // Зависимости
  }
}

Т.е. все зависимости указываются в конфиге сборщика, а не в исходниках.
В шаблоне указываем путь к этому js-файлу:
script src="www.domain.com/fileName.js"

Сборщик находит путь /fileName.js, ищет для этого файла зависимости (depends) и добавляет перед ним HTML-код подключения скрипта lib.js.

Таким образом все зависимости собраны в одном месте, а не разбросаны по исходникам. Кроме этого код файла lib.js не будет дублироваться в собранных файлах. Если же всё таки нужно его дублировать - просто перепишем конфиг без использования depends:

{ // Конфиг сборщика
  'JSCompressor': {
    'configs': [{ // Сначала собираются либы
      'lib.js': {
        'includes': 'lib/*'
      }
    },
    { // Потом остальное
      'fileName.js': {
        'includes': ['fileName/file1.js',
                       'fileName/file2.js']
      },
     { // Конкатенация зависимого кода
       'fileName.js': {
         'includes': ['lib.js',
                        'fileName.js']
       }
     }
    }]
  }
}

Как думаете, такая схема будет удобна?

2-е сообщение в теме.

Ок, первый случай: выпиливаем код сборки script1.js из конфига и script2.js уже не будет подключаться (так как команда подключения в этой части кода).

Второй случай: конфиг сборки создается для всего проекта, а не для отдельных страниц. Если на другой странице мы подключим script1.js - остальное так же подтянется из конфига.

Видимо, ты не до конца вник в схему...

B~Vladi,
ну то есть то же самое, что сказал я, только с выносом подключающих директив в отдельный файл.

Ну получается что так. Остановлюсь пока на этом варианте.

Хм, как-то не красиво получилось. Tim начал про свою либу, а я со своей влез.

B~Vladi,
Всё норм, не парься. =) У меня и либы то собственно не какой нет. Я как раз хотел послушать что другие делают.

Послушал? Что думаешь? :)

Думаю что зависимости нужно будет тоже учитывать, хотя пока необходимости нет да и времени тоже. Спасибо всем кто откликнулся, я ожидал что максимум флудом всё закончится. :)

На что времени нет? У каждого в этой теме есть готовое оттестированное решение. Бери любое.