Поддержка нового стандарта EcmaScript 6 в браузерах все ближе и ближе, и тем кому не терпится начать разрабатывать с использованием новых возможностей ES6 предлагаю взглянуть на шаблонный проект для этой цели.
Представляю вашему вниманию github.com/DavidKlassen/es6-browser-boilerplate.
В основу шаблона лег github.com/babel/babel-library-boilerplate, но gulpfile.js был основательно почищен и упрощен. Многие зависимости я убрал и оставил возможности, которые необходимы для разработки приложений для браузеров.
Основные цели, которые я преследовал:
- Шаблон должен быть хорошей стартовой точкой для разработки SPA и third party SDK.
- Минималистичность и расширяемость.
- Весь код, то есть и само приложение и тесты можно писать на ES6.
Рабочее окружение
Требования к рабочему окружению достаточно стандартные и скорее всего, если вы разрабатываете на JavaScript у вас уже все установлено. Вам потребуется NodeJS либо io.js, NPM, Gulp,
Возможности шаблона
- Для поддержки синтаксиса ES6 используется компилятор Babel.
- Проверка качества кода обеспечивается двумя утилитами, ESLint и JSCS.
- За сборку проекта отвечает browserify и babelify.
- Минификацию кода делает
Google Closure CompilerUglifyJS2. - Unit тесты используют mocha, chai и sinon.
- Отчет о покрытии кода тестами генерируется с помощью istanbul и isparta.
- Integration тесты запускаются в karma.
- В качестве таск раннера используется Gulp.
Как использовать
Скачать и подготовить проект к работе очень просто:
$ git clone git@github.com:DavidKlassen/es6-browser-boilerplate.git
$ cd es6-browser-boilerplate
$ npm run setup
После этого можно удалить .git и начинать кодить.
Список доступных задач gulp:
gulp lint— запускает проверку качества кода с помощью ESLint и JSCS.gulp test:unit— запускает unit тесты.gulp coverage— запускае unit тесты и генерирует отчет о покрытии кода тестами.gulp test:integration— запускает интеграционные тесты в браузере с помощью karma.gulp test— запускает все тесты.gulp browserify— собирает скрипт готовый для использования в браузере.gulp compile— собирает минифицированную версию скрипта.gulp build— собирает обе версии скрипта.gulp— дефолтная задача, запускает проверку кода, тесты и сборку проекта.
Вещи которые хотелось бы улучшить
Помимо всяческих мелочей типа подключения test-frameworks глобально для всех файлов с тестами и мелких улучшений в gulpfile, хотелось бы подключить возможность использования Google Closure Compiler в режиме ADVANCED_OPTIMIZATIONS и статический анализ типов на основе аннотаций gcc.
Ну и конечно же я жду отзывов, пожеланий и пулреквестов. Спасибо за внимание! :)
UPD: В коментариях возник спор о распространенности Java на машинах разработчиков, так что добавляю голосовалку. Если не уверены есть ли java на вашей машине или нет, запускаем:
java -versionUPD2: По просьбам трудящихся заменил google closure compliler на uglifyjs.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (41)
Dreef
29.06.2015 14:07Для оригинала есть также генератор для Yeoman, наверное можно и его адаптировать.
А еще, почему бы не webpack вместо browserify?
f0rk Автор
29.06.2015 14:30Я если честно не пробовал использовать webpack, поверхностный осмотр создал у меня впечатление, что он нацелен больше на разработку SPA. Я хоть и упомянул SPA в статье, но честно признаюсь, последние пару лет я не касался разработки сайтов, больше занимался разработкой всяческих SDK и прочих сторонних скриптов. И естественно, я перенес в шаблон привычный лично для меня сетап. webpack посмотрю подробнее, тем более, что часто слышу про него в последнее время. Можно еще подумать над какой-нибудь pluggable системой сборки, чтоб совсем уж все были довольны :)
AndyGrom
29.06.2015 15:19+6А что, минификацию кода умеет делать только Google Closure Compiler? Для этого нужно такую зависимость от JAVA тащить?
f0rk Автор
29.06.2015 15:24+1Нет, не только, зато closure compiler умеет то, что не умеют другие, например ADVANCED_OPTIMIZATIONS и поддержку аннотаций, это вещи, которые я считаю полезными и хочу прикрутить к шаблону. А Java у многих установлена, так что не думаю, что это большая проблема.
gonzazoid
29.06.2015 16:00>А Java у многих установлена
это у Вас немножко заблуждение.f0rk Автор
29.06.2015 16:08+1www.w3resource.com/browsers/java-support.php
Думаю, что 84% вполне подходит под определение «многих». Подтверждений у меня нет, но подозреваю, что среди девелоперов этот процент еще выше.
beduin01
29.06.2015 17:22-1Думаю статистика вранье. Наверняка ее мерили в самом Oracle. Там еще да. На реальном рынке нет.
impwx
29.06.2015 17:32+1Почему вы так уверены, что именно ваша выборка более честная и репрезентативная?
beduin01
29.06.2015 19:59-1Потому что за много лет ремонта компов и за точно такой же период работы программистом я Java видел дай бог на 5% компов. Ту же самую статистику подтверждают мои коллеги по работе.
Да и зачем она на компе? Софта написанного на ней очень и очень мало.impwx
29.06.2015 20:28+2Охотно верю, что на ремонтируемых вами компьютерах обывателей все это не встречалось. Пускай даже Java обошла вас и ваших коллег-программистов стороной, что маловероятно — однако ваше утверждение все равно голословно. На Java написана добрая половина сред разработки — семейство Idea, семейство Eclipse, Netbeans, клиент Smartgit, разработка под Android также обычно ведется на Java.
beduin01
29.06.2015 21:06-699% пользователей не программисты. Соответственно все это им нафиг не надо. А юзерского софта на Java нет.
Из того, что на Java написано кучу сред не следует, что все или хотя бы большая часть программистов их использует. Опять таки я не видел (хотя и читал про них) ни одного программиста который бы писал в одной из перечисленных сред разработки.
Итог такой: что даже путем диких натяжек и допущений процент Java на десктопах ну никак выше 5 не прыгнет. Ее просто не ставят за ненадобностью.f0rk Автор
29.06.2015 21:57-2Добавил голосовалку в пост, посмотрим, подтвердится ли ваш тезис про 5%.
leschenko
29.06.2015 23:01Уважаемый, вы жонглируете 2 разными цифрами. Данные статистики привели для всех пользователей. А теперь говорите про то, что у программистов Java не редкое явление. Возмущение вызвала именно первая цифра. Т.е. 84%
Среди фронтенд-программистов это вполне реально. Но среди всех пользователей интернета — точно нет.f0rk Автор
29.06.2015 23:14Я не в курсе на какой аудитории собиралась статистика по ссылке которую я привел. Просто запостил первую ссылку, которую смог нагуглить. Упоминаний оракла на их сайте я не нашел. Опрос запостил в ответ на предположение о том что даже с учетом всех натяжек процент не выше 5. Где и чем я жонглирую? Ну не нравятся цифры, приведите свою статистику, никто же не против.
leschenko
30.06.2015 13:59Проблема в том, что вы взяли статистику для одной аудитории и пытаетесь применить ее как аргумент для другой аудитории. Это и есть жонглирование данными.
zxcabs
29.06.2015 23:52+2Добавьте тогда сразу кто ставит джаву для минификатора гугловского, у меня джава стоит но только в силу тех причин что она необходима для запуска IDE. В противном случае вообще не вижу иметь ее на машине. Для минификации использую углифайжс.
leschenko
29.06.2015 20:19Я тоже считаю что 84% это перебор. Java на клиентских windows встречается очень редко. В отличии от .net из коробки ее нет. А надобности в ней мало.
Обычный пользователь скорее всего не знает что такое Java или .NET и зачем оно. Поэтому вряд ли будет ставить сам. Только если Java нужна какому-то другому софту. А много вы софта знаете (для обычного пользователя), который требует Java?
Вот .NET может быть установлен и пользователь может не знать об этом и не использовать его.
monolithed
30.06.2015 00:50По существу, о GCC
Минусы:
1. Требуется Java (на домашнем ПК это не проблема, но на сборочном сервере для этой задачи ее ставить мало кто решится).
2. Отсутствует привычное JS-API (даже официальный npm-пакет не предоставляет такой возможности).
3. Долгий процесс компиляции.
4. Большой размер пакета (6.3 Mb в сжатом виде), для CI это минус.
5. Чтобы использовать ADVANCED_OPTIMIZATIONS нужно писать сложно читаемый код (использовать скобочную нотацию, забыть про модульность, избегать void function, держать файлик с аннотацией глобальных переменных и пр.) иначе можно недосчитаться нужного куска кода. Без достаточного опыта лучше не пытаться использовать этот режим.
6. Линтер успешно заменяет ESLint, он даже более предпочтителен, т.к. имеет поддержку ES6.
7. Не все аннотации совместимы с JSDoc 3, это может быть проблемой для каких-то редакторов кода.
8. Нет особого смысла использовать GCC вместо Uglify если сервер отдает Gzip. Такой проблемы попросту не возникает.
Когда-то я писал вот-такие замечательные скрипты и радовался до безумия статическому анализу, но когда в Uglify поддержали AST я без сожаления перешел на него, а со статический анализ доверил ESLint и пока ни чуть не жалею.some_x
30.06.2015 07:03а в чём проблема поставить яву на сервере?
leschenko
30.06.2015 11:41не безопасно это.
f0rk Автор
30.06.2015 13:27-1> не безопасно это.
Серьезно? Небезопасно иметь жаву на билд-сервере? Расскажите поподробнее, какие угрозы это несет.leschenko
30.06.2015 13:54-1Кто говорил про билд сервер? Сказано было просто «на сервере».
И да — установка любого нового компонента, уменьшает безопасность системы в целом, так как этот компонент может содержать в себе разного рода уязвимости.
То, что в вашем случае это билд сервер, он отключен от сети, стоит в бункере, данными с внешним миром обменивается через дискеты — это уже другая история, не имеющая отношения к первоначальному вопросу.f0rk Автор
30.06.2015 15:05> Кто говорил про билд сервер?
monolithed говорил
> но на сборочном сервере для этой задачи ее ставить мало кто решится
Какое вообще отношение имеет «просто сервер» к контексту данного топика? Куда-то вас не в ту степь понесло. Здесь java используется исключительно для сборки пакета, с трудом представляю себе сценарий в котором это будет представлять угрозу безопасности. Чушь какая-то…
monolithed
30.06.2015 14:46Любой пакет нужно мониторить и поддерживать и конфигурировать, для такой пустяковой задачи выделять время админов и безопасников никто не будет, поскольку это нецелесообразно.
Поставить же npm-пакет значительно проще, особенно есть уже есть свой npm-репозиторий и для этого не нужно рутовых прав.f0rk Автор
30.06.2015 15:12ИМХО проблема высосана из пальца, говоришь админу «поставь пакет %name% на билд-сервер, он нужен для сборки» и через 10 минут все готово, они для того и нужны (админы). Поверьте, я на разных по масштабу проектах работал, в том числе и на требующих повышенного контроля с точки зрения безопасности, ни разу не видел чтоб конфигурация билд-сервера кого-то волновала.
monolithed
30.06.2015 17:14проблема высосана из пальца, говоришь админу «поставь пакет %name% на билд-сервер, он нужен для сборки» и через 10 минут все готово, они для того и нужны (админы).
Любое решение требует согласования. В данном случае, мне бы потребовалось обсудить это решение со своим непосредственным руководителем, специалистом который отвечает за деплой, специалистом по безопасности и админами, которые в свою очередь тоже должны это обсудить со своим руководством чтобы выделить время на конфигурирование машин.
Поверьте, я на разных по масштабу проектах работал, в том числе и на требующих повышенного контроля с точки зрения безопасности, ни разу не видел чтоб конфигурация билд-сервера кого-то волновала.
Требования к пропакшн серверам и серверам на которых собирается релиз одинаковые. Странно это даже обсуждать.f0rk Автор
30.06.2015 17:23> Любое решение требует согласования.
Могу только посочувствовать этому примеру явно неадекватной бюрократии.
> Требования к пропакшн серверам и серверам на которых собирается релиз одинаковые. Странно это даже обсуждать.
Эээ… билд сервера — это сервера на которых собирается код. Мы точно об одном и том же говорим? К ним должна иметь доступ только CI система, публичных сетевых интерфейсов они иметь не обязаны, с чего бы к ним такие же требования предъявлять?monolithed
01.07.2015 01:09Могу только посочувствовать этому примеру явно неадекватной бюрократии.
Далеко не все разработчики обладают достаточной квалификацией и способностью нести ответственность за свои решения и уж тем более мало кто может самостоятельно определить трудозатраты других сотрудников.
Эээ… билд сервера — это сервера на которых собирается код. Мы точно об одном и том же говорим? К ним должна иметь доступ только CI система, публичных сетевых интерфейсов они иметь не обязаны, с чего бы к ним такие же требования предъявлять?
После того как пакет собрался (CI) его нужно доставить на рабочие сервера (CD). Не думаю что сюрпризы в пакете кому-то понравятся.
Dmitry_f
02.07.2015 23:25npm install closurecompiler я один додумался и всегда делаю?
Превосходное API, как CLI, так и программно, поддержка пайпов, сорсмапов, хотя последнее никогда не требовалось. Компилится незначитьно дольше углифая.
Но в целом да, uglify2 проще.
Alex_At_Net
29.06.2015 18:22Очень интересно, спасибо.
На сколько трудно будет его подружить с Go проектом? Т.е., например, у меня тесты для Go и автоматизация через makefiles. Будет ли стратегия proxify gulp commands through the makefile tasks правильной?f0rk Автор
29.06.2015 18:50Я бы не стал смешивать код бэкенда с клиентским в случае разработки sdk или spa.
k12th
30.06.2015 11:54Кто первый форкнет и заменит closure compiler на uglufy2 — тот молодец и тому плюсик в карму (не только здешнюю, но и IRL):)
f0rk Автор
30.06.2015 12:06+3Делов то :)
$ rm bower.json
uglify.patch:
diff --git a/gulpfile.js b/gulpfile.js index 11f787a..c2fb852 100644 --- a/gulpfile.js +++ b/gulpfile.js @@ -7,10 +7,10 @@ const istanbul = require('gulp-istanbul'); const babelify = require('babelify'); const browserify = require('browserify'); const source = require('vinyl-source-stream'); -const closureCompiler = require('gulp-closure-compiler'); const karma = require('karma').server; const isparta = require('isparta'); const babel = require('babel/register'); +const uglify = require('gulp-uglify'); function unitTests() { return gulp.src(['tests/unit/**/*.js']) @@ -69,10 +69,7 @@ gulp.task('browserify', function () { gulp.task('compile', ['browserify'], function () { return gulp.src('dist/lib-build.js') - .pipe(closureCompiler({ - compilerPath: 'bower_components/closure-compiler/compiler.jar', - fileName: 'lib-build.min.js' - })) + .pipe(uglify()) .pipe(gulp.dest('dist')); }); diff --git a/package.json b/package.json index 208bbd3..afbe449 100644 --- a/package.json +++ b/package.json @@ -22,6 +22,7 @@ "gulp-istanbul": "^0.10.0", "gulp-jscs": "^1.6.0", "gulp-mocha": "^2.1.2", + "gulp-uglify": "^1.2.0", "isparta": "^3.0.3", "karma": "^0.12.37", "karma-browserify": "^4.2.1",
$ npm i
dannyzubarev
ES2015 же. :)
www.ecma-international.org/publications/standards/Ecma-262.htm