Переменные окружения

[ilyar]

Думаю не верно указывать переменные окружения в make.js, будет правильно выделить их в документацию

export YENV=production
export XJST_ASYNCIFY=yes
export BEM_MAKE_NO_COLORS=yes
export BEM_MAKE_VERBOSITY=error

хотя, если они переопределяются то это не важно.

[ilyar]

Также теперь переменная окружения в make.js берется из project.json

@verybigman хорошо, а это правильно? Получается YENV указываем в project.json, а BEM_MAKE_VERBOSITY , будет устанавливаться в переменные окружения, может быть переменные окружения останутся переменными окружения и их просто задокументировать?

[awinogradov]

@ilyar verbosity можно указывать из gruntfile:

bem: {
            merge: {
                workers: 10,
                verbosity: "error",
                command: "make"
            }
        }

Тоже самое касается и цветов.

В моем решении ты управляешь проектом из одного места. Переменные влияют на всю сборку (bem make и возможно другие таски в gruntfile). В твоем варианте придется переменные менять в 2х местах. Это как минимум неудобно. А во вторых, может создать ситуацию когда make работает в production, а проект в development.

[ilyar]

Спасибо за пояснение. Полагал, что, в данном контексте, перемененные окружения используются при сборке или запуске проекта для указанию сборщику или механизму инициализации как следует действовать и какие опции использовать. Сталкивался таким подходом в 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

Вероятно это вопрос предпочтений.

[awinogradov]

Я знаю о чем ты говоришь и да решается через 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. Думаю ты понимаешь о чем я.

[ilyar]

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

[awinogradov]

Не вижу особых проблем для использования параметров из кофига в разных окружениях. В конечном счете все так и работает. Переключая режимы, те или иные функции работают по разному и если ты не видишь, где это описано, это не значит, что это не описано в конфиге или что так нельзя сделать, ведь именно так и есть с борщиком. Именно так работают и рельсы. Да сейчас эти переменные влияют только на сборку, но это только потому, что особой разницы между окружениями нет. Ты сам можешь создать эту разницу. Опиши в конфиге разные реализции одной функции и используй в каждом окружении свою. К примеру так ты можешь описать роутинг за данными. В девелопменте использовать локальный json, а в проде ходить в апи. Может проблема в том, что ты не можешь из шаблнов ходить в конфиги?

[ilyar]

понятно, проблем нет, спасибо.