Feature request: Greater flexibility on where project configuration options need to be stored

[paulrobertlloyd]

This can certainly be filed under ‘nice to have’, but needing a fractal.js file in the root of a project sits a little uncomfortably with me; especially as it mainly consists of configuration options, which seem better suited to being in a JSON/YAML file of some description (assuming no JavaScript additions are needed).

This niggle is further reinforced having recently spotted cosmiconfig, a project whose philosophy seems similar to that of fractal. This package allows projects to be unopinionated about how and where configuration is provided (be it a .fractalrc file, inside package.json, a fractal.config.js file, --config options within the CLI etc. etc.). Worth a look!

[allmarkedup]

I have to say I disagree - I think it's useful to think of it as an 'application bootstrap' file rather than a config file, as for doing anything slightly more complex (like adding custom handlebars helpers, as you did) it really needs to be JS.

What are you adding to the file that you find laborious? If you need to set default context or other things like that you can actually do this in a JSON/YML/JS config file in the root of your components directory too.

[paulrobertlloyd]

Okay… can the contents of fractal.js be stored in another file…for example an index.js file (perhaps one which is part of broader application bootstrap file)?

[allmarkedup]

Unfortunately, if you want to run fractal from the command line, then it needs to be called fractal.js. The reason is exactly the same for why your gulp file must be called gulpfile.js and the same for grunt - the global CLI helper needs to look for a file with a specific name so it knows what to use to run commands against.

However in theory you could do the actual configuration in any JS file you like and then just require that file into an otherwise empty fractal.js file - but the fractal.js file would still need to be there. For example something like this: https://gist.github.com/allmarkedup/67a71e49b6f6cc083466

What is the use case for changing the name? Is there something specific or is it just in the name of flexibility?

[paulrobertlloyd]

More in the name of project hygiene really, i.e. reducing the number of config files, runners etc. etc. in a root folder. Not a big deal, just wanted to make sure files aren’t being mandated if other options available. Closing.