Closed ilyar closed 10 years ago
Также теперь переменная окружения в make.js берется из project.json
@verybigman хорошо, а это правильно? Получается YENV
указываем в project.json
, а BEM_MAKE_VERBOSITY
, будет устанавливаться в переменные окружения, может быть переменные окружения останутся переменными окружения и их просто задокументировать?
@ilyar verbosity можно указывать из gruntfile:
bem: {
merge: {
workers: 10,
verbosity: "error",
command: "make"
}
}
Тоже самое касается и цветов.
В моем решении ты управляешь проектом из одного места. Переменные влияют на всю сборку (bem make и возможно другие таски в gruntfile). В твоем варианте придется переменные менять в 2х местах. Это как минимум неудобно. А во вторых, может создать ситуацию когда make работает в production, а проект в development.
Спасибо за пояснение. Полагал, что, в данном контексте, перемененные окружения используются при сборке или запуске проекта для указанию сборщику или механизму инициализации как следует действовать и какие опции использовать. Сталкивался таким подходом в Rails проектах, мы имеем конфиг project.yml:
production: &base
param: A
development:
<<: *base
param: B
test:
<<: *base
param: D
в результате в зависимости от окружения будет собран или инициализирован с разными условиями и логикой:
RAILS_ENV=production script_do_something
В твоем решении это решается конфигурацией grunt
и есть возможность настроить такси grunt
и grunt production
Вероятно это вопрос предпочтений.
Я знаю о чем ты говоришь и да решается через Grunt. Ничто не мешает тебе прописать подобные условия в project.json для каждого окружения.
Например так:
"env" : "development",
"settings" : {
"development" : {
"param" : "A"
},
"production" : {
"param" : "B"
}
}
Далее вызывай:
var project = require('./project.json');
var param = project.settings[project.env]["param"];
Надуманный пример, но рабочий. В реальности можно сделать и лучше :)
На мой взгляд нужно использовать привычные инструменты и методы. Не надо тянуть старые привычки в новое окружение. В Rails пишут в .yml, но на фронте пишут .json и .js. Думаю ты понимаешь о чем я.
да я понял, но я хотел обратить внимание не на формат записи конфига, а на использование переменных окружения, в надуманном примере, это конфиг для разных режимов сборки или запуска, а собирать или запускать проект в разном окружении это другое.
Не вижу особых проблем для использования параметров из кофига в разных окружениях. В конечном счете все так и работает. Переключая режимы, те или иные функции работают по разному и если ты не видишь, где это описано, это не значит, что это не описано в конфиге или что так нельзя сделать, ведь именно так и есть с борщиком. Именно так работают и рельсы. Да сейчас эти переменные влияют только на сборку, но это только потому, что особой разницы между окружениями нет. Ты сам можешь создать эту разницу. Опиши в конфиге разные реализции одной функции и используй в каждом окружении свою. К примеру так ты можешь описать роутинг за данными. В девелопменте использовать локальный json, а в проде ходить в апи. Может проблема в том, что ты не можешь из шаблнов ходить в конфиги?
понятно, проблем нет, спасибо.
Думаю не верно указывать переменные окружения в
make.js
, будет правильно выделить их в документациюхотя, если они переопределяются то это не важно.