environments concept

[jasonkuhrt]

This idea comes from use-cases I've routinely encountered. The premise is that we expose environment variable COMPONENT_ENV via e.g. require('env').* and also let users hook onto its value in component.json so that we can have branches of component.json that are resolved only if in the respective env, e.g.:

"env-prod": {
    "dependencies": {
        "reactjs/reactjs-min"
    }
},
"env-dev": {
    "dependencies": {
        "reactjs/reactjs"
    }
}

This is rough, but I think the premise is sound, again it solves real problems I've encountered. I often have env-aware client projects etc. Am I an exception here or can we turn this into a positive for general use?

• This should be a plugin but that has been a PITA even when working with builder.js from scratch.

[micky2be]

I personally don't like to have 2 different behaviours between prod and dev. Why would you need different version of the same dependency?

I also usually minify the build for production release. So having the dependency already minified doesn't provide any help.

[jasonkuhrt]

Other use-cases:

• we don't need to special-case development anymore, it would just fall out from this feature simply, e.g.: component install mocha --env development
• becomes easier to support stuff like #512, #517 wherein the build is shaped by the env

[jasonkuhrt]

@micky2be

I personally don't like to have 2 different behaviours between prod and dev.

I don't really understand this statement, sorry. Can you elucidate?

Why would you need different version of the same dependency?

I also usually minify the build for production release. So having the dependency already minified doesn't provide any help.

I agree in principal but its not that simple. Please refer to https://github.com/reactjs/react-bower/issues/1 and https://github.com/facebook/react/issues/1635.

[micky2be]

I don't really understand this statement, sorry. Can you elucidate?

You'll have to setup 2 different dependencies based on your environment. Nothing guaranty that user/repo-min act the same as user/repo. And it's becoming difficult to manage. But that's just my opinion and how I manage my projects.

[jasonkuhrt]

@micky2be Yup. But until component provides support for multi-dist components (if ever, is philosophically opposed currently) this feature would provide a low-labour work around. Also, this isn't the only use-case.

For COMPONENT_ENV I rely on it for making sure I load the correct config branches for my application. It turns out my client projects often rely on lots of different cloud services so being able to require('env') makes it trivial to get the right URIs for those respective to the env in use.

[jasonkuhrt]

FWIW, were the following true, would make me very happy to not have this:

1. projects better-expose their build tools in a cli so that we're not stuck requiring multi-dist components https://github.com/reactjs/react-bower/issues/1#issuecomment-46578277
2. a robust .use() system that makes it easy to inject synthetic files etc.
3. --use support https://github.com/component/component/issues/524

But since:

1. is not realistic
2. is not happening any time soon
3. depends on 2 plus additional discussion

I don't see a way forward other than some simple interface tweaks to compoent.

[netpoetica]

@jasonkuhrt in your original post, you show reactjs/reactjs and reactjs/reactjs-min - I'm probably missing something, but are you implying that component authors should be maintaining releases for minified and non-minified versions of their components?

I definitely have encountered this type of use case before. Generally I find myself using component to generate standalone components which I then manage via Grunt builds, where I can actually automate tasks based on environment. AKA I rarely ever have projects that contain a component.json themselves, unless they are small modules shared across multiple projects, which I usually just build as standalone items.

I am not sure that the solution of creating builds per environment really covers the full breadth and depth of problems opened up by some of the various use cases I have encountered so far, have to put some more though in to that

[jasonkuhrt]

@netpoetica Hey

but are you implying that component authors should be maintaining releases for minified and non-minified versions of their components?

Ideally no, but certain circumstances point in that direction. I've given up thinking about this problem space for now, too complicated for me right now. There's a cascade-like series of problems that need addressing, starting with how difficult component plugins are to employ. I don't feeling like bitching though because I would rather just help, but that's near impossible for me until later this year.

[jasonkuhrt]

All too nutty, never going to happen.