Setting hide_unoptimized_assets to false causes an InvalidConfigurationException

[andersaloof]

In my config.yml file I've set hide_unoptimized_assets to true, and I have a working environment where r.js builds a single js file of the application, when I dump the assets with the assetic:dump console command etc.

However, in my dev environment (where nothing is supposed to be built into a single file), requests for the js files fails with a 404, when hide_unoptimized_assets is set to true (No route found etc). So I tried to set hide_unoptimized_assets to false in my dev settings, but that fails with an InvalidConfigurationException ('The path "hearsay_require_js.optimizer.hide_unoptimized_assets" cannot contain an empty value, but got false'). Looking at the configuration of the bundle, hide_unoptimized_assets is not allowed to be empty (cannotBeEmpty()). Removing this from the configuration makes everything work perfect.

Is there a reason why this is not allowed to be set to false, or could this limitation (cannotBeEmpty()) be removed?

[ihortymoshenko]

@andersaloof, the default value is false.

[andersaloof]

Sorry to bother you again, but yes, I know the default value is false, but that doesn't solve my problem/challenge.

I have the following setup:

• hide_unoptimized_assets is set to true in config.yml
• config_dev.yml inherits config.yml settings via import resource

Since hide_unoptimized_assets is set to true in config.yml and the configuration of that parameter specifies that it cannotBeEmpty, I am not allowed to override the inherited setting of true in my dev environment. Since i've specified it to be true in the prod environment, it doesn't help that the default is false, it's not possible to override.

[craigmarvelley]

@IgorTimoshenko I also think the issue is valid - if someone wanted to set the value of this config property to be equal to a container parameter, they wouldn't be able to toggle the value of that parameter to false, they'd have to modify their config to remove the node. As the use of booleanNode enforces the type of the value, surely that's sufficient?

[ihortymoshenko]

Ok, fixed. Thanks :)

[andersaloof]

Great :)