some .componentrc or other environmental configuration file

[jonathanong]

for stuff like:

• installation name
• build directory
• build name
• standalone name
• custom remotes (i.e. replace the github remote with your own)
• proxy

the primary reason is that a lot of the CLI utilities need these variables, but putting them all as an option every time is a little annoying. it'll also make --help less verbose.

note that this is only for local configurations. the entire build should work with and without this config file.

alternatives:

• add an object to component.json like .builder
• use only environmental variables

references:

• Please reintroduce --out #462
• Add "standalone" option to component.json #512

[cristiandouce]

I personally don't like the environmental variables alternative.

And I don't see why I wouldn't be allowed to have a global configuration setup ~/.componentrc and a per-project one at the same level of component.json.

Also, along with the custom remotes, we could avoid using the .netrc for github authentication and place it all there. IMHO

[cristiandouce]

On the other hand... I see the advantage to sometimes have the chance to override "some" configs via ENV vars... in PaaS like heroku for example.

hmmm... tricky choice.

[jonathanong]

yeah that's basically how .rc files will work if we go that route. i think a componentrc should supercede any netrc files as well.

i'm also thinking of adding more properties like BUILD = ../path/to/my/custom/builder, etc. might be helpful instead of reimplementing all the component JS logic

[jonathanong]

i was thinking of a .componentenv file (or .env or whatever. not sure if there's already a standard) that look like environmental variables. then internally, we can treat all the settings as environmental variables. so instead of .env files, you can actually use environmental variables instead.

[netpoetica]

I'm not positive that environmental variables would be the best way of handling this because of the usecase where someone who is technically working on 1 large component that contains a couple of smaller components. Due to the current philosophy behind component, it makes sense to separate these components into separate "projects" (aka folders with a root level component.json),so you find yourself going in and out of each component folder to run "component build" in order to ultimately generate a couple of components for consumption within one over-arching project. I'm already picturing that during fast-pace development people forget to change env vars and end up with the wrong settings generating the wrong builds, with errors resulting in more Github issues

[jonathanong]

the idea behind .env files is that these environmental variables would only be set when you run a component command inside the project, so moving in and out of different projects wouldn't matter.

[netpoetica]

Ah , gotcha. I thought you meant manually settings environment variables via shell

[krainboltgreene]

Can I do anything to resolve this? Because componentjs is amazing to me and I want this to be a part of it.

[timaschew]

@krainboltgreene what is exactly so amazing?

I don't think anyone will put new effort into component, see #639

[krainboltgreene]

It's exactly what I want and perfect for web components. I'm annoyed that it's not moving forward.

[timaschew]

can you describe which concept is perfect and why other tools are not suitable?
maybe we provide these concepts in tools like webpack via plugins