RC-Paves3-build / plovr

Automatically exported from code.google.com/p/plovr
0 stars 0 forks source link

Allow for multiple configurations inside a single config-file #8

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Right now, inside a project with multiple compile targets/apps I have to keep 
several config-files; one for each app.

To serve them all currently I'd need to do something like:
java -jar plovr.jar serve app1.js app2.js appN.js ...

Would be nice to be able to manage all configurations inside a single file. 
Managing that one file might be easier and using the commandline would be more 
comfortable, like:
java -jar plovr.jar serve apps.js

Thanks for an absolutely great tool! : )

Original issue reported on code.google.com by carsten.kraus on 24 Aug 2010 at 2:22

GoogleCodeExporter commented 9 years ago
Well, you could also do:

ls -1 *.jar | xargs java -jar plovr.jar serve

But I realize that's not what you're looking for. I do see the use case for 
this -- could you put together some examples of what you think the format 
should be?

I am planning to add support for "config file inheritance" so you could set 
your compilation options in one file and then have individual files "inherit" 
those config options. So if it were possible to declare multiple configs in one 
file, I think that the idea of sharing some settings across configs would still 
need to be preserved.

Original comment by bolinf...@gmail.com on 30 Sep 2010 at 8:00

GoogleCodeExporter commented 9 years ago
In my team there are some people working on windows, so their shell wont help 
them too much here, I guess : )

Anyway, besides the increased comfort that managing only a single config file 
would bring:  
typing 'java -jar plovr.jar serve apps.json' would just even be a little more 
convenient than the piped statement above.
Potential closure users are sometimes 'just' frontend-devs with possibly little 
cli experience(yet), so I think the easier the better.

'Config file inheritance' sounds awesome! Thinking about it, it could even 
solve some things that I thought would make using ant or some other build tool 
necessary. For example, creating separate builds for dev, stage, production or 
similar.

Having that in mind, an idea for a config file making use of multiple apps & 
inheritance:
// file: apps.json
{
    // master config. 'abstract': not servable nor buildable(no 'inputs')
    "id":"master",
    "mode":"advanced",
    "paths":["goox", "moox"],
    "externs":["ext/maps.js", "ext/ga.js"]
},
{
    // widget only code, used by third party sites, etc.
    "id":"widget",
    "extends":"master",
    "inputs":"wigdet.js"
},
{
    // full fledged app
    "id":"app",
    "extends":"master",
    "inputs":"app.js"
},
{
    // api for 3rd party devs to use. only exports data, net stuff from app
    "id":"api",
    "extends":"master",
    "externs":null,
    "inputs":"json-api.js",
},
{
    // debug version of the api. adds logging, more readable
    "id":"api-dev",
    "extends":"api",
    "mode":"whitespace",
    "output":"api.debug.js"
}

How it could work: 
The serve cmd just checks for the 'id' query string param to serve the 
requested target.
The build cmd builds & writes a file for each config that either has an 
'inputs' value on its own or inherits from a config that has one. Filenames are 
constructed using the id field by default, eg 'api.js'; when 'output' is given 
its value is used instead.
Inherited fields can be overwritten and eg. nulled(see api.externs). 
Dont have a good idea how to augment inherited fields right now, maybe sth like 
"paths:['base_.paths', 'logging']" or so?

Hope, this comment isnt too long :D

Original comment by carsten.kraus on 1 Oct 2010 at 7:16

GoogleCodeExporter commented 9 years ago

Original comment by bolinf...@gmail.com on 14 Oct 2010 at 5:02

GoogleCodeExporter commented 9 years ago
I added support for an "inherits" option in 
http://code.google.com/p/plovr/source/detail?r=0a68ff1f9aab3e430e3c2b350f33c398e
ef3fb27

I know that's not what you proposed, though what you proposed above also won't 
parse under a strict JSON parser because it does not have a root. plovr expects 
that root to be a map (rather than an array), so at a minimum, you'd have to 
add another two levels of indent for your thing to work: a root map (1) with an 
property whose value is an array (2) of the configs you list above.

I'd encourage you to build plovr from source and try out the new "inherits" 
option and let me know if it works for you.

Original comment by bolinf...@gmail.com on 21 Jun 2011 at 4:38

GoogleCodeExporter commented 9 years ago
As discussed in the Google Group 
(https://groups.google.com/group/plovr/browse_thread/thread/b2b4454e7810a031), 
it seems the consensus is to prefer config options to command-line arguments, 
so I'm going to declare config inheritance as the official way to go with this 
one rather than supporting multiple configs in the same file. Thus, I am 
closing this issue as WontFix.

If this is really an issue for you, I recommend writing a script to generate 
all of the configs. In practice, I have only run into this issue when creating 
plovr configs for unit tests (of which you should have many!). I have put 
together a bash script that works for me, but I'm planning to port it to Java 
and include it as part of plovr.

Also, I just checked in support for generating a deps.js, so using 
base.js/deps.js is also a good alternative to creating a plovr config every 
time you want to build something.

Original comment by bolinf...@gmail.com on 14 Oct 2011 at 1:22