я после месяца отсутствия скорее всего вообще ни в чем не смог бы разобраться

Думаю эти два решения как раз можно соединить: 1. Переименовать package.xxx.json => package.json 2. Сделать npm install, собрав node_modules 3. Собрать my-app-xxx Но как в этом случае отслеживать изменения? Принудительно дергать при изменении package.json?

Кодовую базу по чайным пакетикам?

Сервисов много, а код один?

Это точно _микро_-сервисы?

Да, а какие есть альтернативы?

Но тут не совсем сервисы

не, это бывает, у меня такая же тема

Это больше джобы

в идеале просто заюить и использовать одие package.json

Ну у нас были дамб мсы - один код разные конфиги

Например - протестировать UI, вытащить переводы из кода, залить их обратно и тд

в идеале просто заюить и использовать одие package.json

Тогда получаем большой node_modules, один для всех

в целом ОК, но падает реюзабельность

так все так есть смысл разделять репо

смысл слов “единая кодовая база” теряется

Чтот, Денис, мне кажется, херню ты сделал

Да я бы рад услышать лучшие идеи )

Но вот например тот же скрипт i18n парсит кодовую базу и извлекает переводы

а в чем проблема все зависимости в 1 package.json держать?

Но вот например тот же скрипт i18n парсит кодовую базу и извлекает переводы

ну это скорее из области devdependency

@gusnkt Была проблема с долгим npm install, но с учётом отдельного image для node_modules, это уже не актуальная проблема)

@gusnkt Была проблема с долгим npm install, но с учётом отдельного image для node_modules, это уже не актуальная проблема)

ну вот да. в circle ci очень быстро зависимости ставятся, например

то есть надо грамотно кешировать package.json

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

ну наверняка каждая часть в своей папке

если ты не держишь все в одном - у тебя будет другая проблема. Во всех пакетах обновить babel, линтер, lodash, etc.

положи туда package.json

если ты не держишь все в одном - у тебя будет другая проблема. Во всех пакетах обновить babel, линтер, lodash, etc.

это все в общем

если ты не держишь все в одном - у тебя будет другая проблема. Во всех пакетах обновить babel, линтер, lodash, etc.

вто и я про тоже)

ну кстати да) шареные зависимости в root, остальные в отельные package.json

не, один основной, и в каждой папке свой

два npm install

и прям 99% - есть тулза, которой даешь пути к остальным package.json, и в postinstall

А вот кстати про postinstall такая инфа поступила :)

If there is a binding.gyp file in the root of your package, npm will default the preinstall command to compile using node-gyp `BEST PRACTICES Don't use install. Use a .gyp file for compilation, and prepublish for anything else. You should almost never have to explicitly set a preinstall or install script. If you are doing this, please consider if there is another option. The only valid use of install or preinstall scripts is for compilation which must be done on the target architecture.`

https://docs.npmjs.com/misc/scripts#best-practices

ну эт не новость

по хорошему скрипты должны быть задизейблены при инсталле

задизейблены?

для безопасности

Для меня, кстати, новость - я относитлся к postinstall как секции, откуда можно дёрнуть build, например, чтобы два раза в консоль не ходить)

для безопасности

Тогда node-gyp и пр отвалится ж)

ручками запускать

Так он сам же может запускаться, это же фича

а то в binding.gyp тоже может быть всякое

Ну так то и в модулях может быть всякое)

может!

но не в момент инсталла

да, стоит разделять install и build

Внезапно осознал

)

install надо переименовать в fetch

С другой стороны, вот есть package.json: { "name": "my-app", "version": "1.0.0", "private": true, "author": "Startup Makers", "devDependencies": { "browserstack-local": "^1.0.0", "nightwatch": "^0.9.5" }, "engines": { "node": "5.x", "npm": "3.x" }, "scripts": { "test": "./node_modules/.bin/nightwatch -c nightwatch.conf.js -e chrome_51,ios_9", "test:local": "node browserstack.local.js" } }

и чё-то не сильно бы его хотелось мешать с основным большим package.json

Поэтому вариант вначале смотрится лучше всего

Думаю эти два решения как раз можно соединить: 1. Переименовать package.xxx.json => package.json 2. Сделать npm install, собрав node_modules 3. Собрать my-app-xxx Но как в этом случае отслеживать изменения? Принудительно дергать при изменении package.json?

Up!

Ребята, мне надо реализовать голосовалку, так вот, сейчас думаю, результаты голосовалки луше вычислять каждый раз при запросе или все таки их в базе надо хранить?

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

А зачем их считать если они не меняются пока не было голоса?

Голос появился - пересчитали - сохранили

можно не хранить для начала, оставить как оптимизацию

да да, история про 7 нулей

я

Опередил:)

А что нужно? Express?

connect

а вообще - require('http') и вперед

да, это вообще норм

Ребят, решил я таки забахать небольшой проект) Фронт - простая страничка на реакте (очень маленькая). А вот сервак рабтает как API, сам ничего не рендерит. Хотелось бы юзать все плюшки ES6/7, а, следовательно, надо настроить webpack. Так вот в гугле слишком много инфы, как настроить его для фронта, но нет ничего для бека. Мне бы автосборку проекта и автоперезагрузку при обновлении (автоперезагрузку именно сервера, без клиента), есть годные мануалы?

документацию открыть, не??

https://webpack.github.io/docs/

Открывал) Там куча инфы про webpack-dev-server и ему подобных. А вот как то же самое сделать для сервера не нашел (:

Единственное что пока пришло в голову - вешать observer на файл, а node запускать через child_process. Как файл меняется убивать старый процесс и запускать новый.

вебпак для бэка

вебпак для бэка

а как инлайн стили можно сбилдить не теряя модульность?вебпак это может?

а как инлайн стили можно сбилдить не теряя модульность?вебпак это может?так чтобы это можно было быстро внедрить в деплой

магия разве только в маленькой функции, которая делает композицию мидлверов, а в остальном он минимальный и не далек от express..

Напоминаю, что у нас есть чат @javascript_jobs