.assetgraph configuration file (DISCUSSION) #74
Comments
|
Looking into this a bit now as part of getting rid of First take: inline in the HTML: <html data-supportedlocaleids="en_us,da,de" data-localecookiename="MyLanguageCookie">or on the devMode include: <script src="devMode.js" data-supportedlocaleids="en_us,da,de" data-localecookiename="MyLanguageCookie></script>
Both would be annoying in projects that have more than one HTML file, because the config would have to be duplicated. So I thought it might be useful to put them in an explicitly linked configuration file residing in the document root: <script src="devMode.js" data-config="myProject.json"></script>With {
"localeCookieName": "MyLanguageCookie",
"supportedLocaleIds": ["en_us", "da", "de"]
}But there's no reason why that config file couldn't contain all those other config options as well -- in which case the I honestly can't figure out if adding a config file like this smells too much. But I can't really come up with a better idea of how to configure the development mode script in one place. |
|
I'm not sure about the concept of having to relate the html to a config file. Is this to cater to several different setups within the same project? Most other build tools get along fine with a config file pretty much following the unix dotfile concept. I just ran into another use case today, where having the configuration in a file instead of having to type it into the command line is helpful. Windows compatibility. My default setup is just to create a Makefile, but that puts a bunch of requirements on the windows user, where a dotfile in the project would reduce the build to |
|
I've implemented this at least partially. Current behavior is now this:
From here on out it runs the usual magic to translate configuration paths to file system paths etc. The last point on the list is a problem. I want the behavior to be that any command line option overrides any default and anything set in the config file. However optimist fills in the defaults into Is the config file lookup to extensive? I've tried mimicking linux standard dotfile behavior, but I am not certain assetgraph configuration is reusable across projects in that way. Maybe it should be altered to only look for a config file in the current directory. Possible more things to implement
@papandreou Any inputs? And would you be able to test this? |
|
I'm working on my own implementation that's tied closely to the bootstrapper script, which will become a static script of its own. For the reasons stated above the config file needs to be fetchable by the frontend code, so those config file locations you mention won't work, and for now I'm on the fence about introducing a second config file. |
|
This seems to cover a lot of bases. Might be a nice way to go not only for configuration, but also for bootstrapping all out assetgraph command line tools |
|
I don't fully understand -- what exactly do you mean by "This"? |
|
Just for the record -- a while ago I mentioned to @Munter offline that my plans wrt. configuring that bootstrapper script have changed somewhat, so I'm no longer on the fence about introducing a config file for that reason :) |
|
lol, forgot to paste the link :) |
I was thinking that it might make sense having assetgraph-builder able to retrieve configuration from a
.assetgraphconfiguration file, working in the usual dotfile manner.It might give some benefit to the developer being able to store all the build configuration in this file instead of having to write a *ake-file just to invoke buildProduction the same way each time.
Further more I think it might give some future possibilities having the configuration in a well defined file. For example if we want to build assetgraph into other parts of the workflow, like an editor plugin, so they can share the configuration or parts of it.
The text was updated successfully, but these errors were encountered: