Allow empty (null) lists

[lionello]

This happens when some users are not very familiar with the Compose file syntax: during testing they'd comment out the environment variables, but not the actual environment: key, and the Compose file would fail to load:

services:
  service1:
    build: .
    environment:
      #NODE_ENV: production

This change adds "null" as a valid type for many of the lists in the JSON schema:

• include
• service.blkio_config.device_read_bps
• service.blkio_config.device_read_iops
• service.blkio_config.device_write_bps
• service.blkio_config.device_write_iops
• service.blkio_config.weight_device
• service.expose
• service.group_add
• service.ports
• service.volumes
• development.watch
• deployment.placement.preferences
• generic_resources
• devices
• network.ipam.config
• command
• env_file
• list_of_unique_strings (was: list_of_strings)
• list_of_strings
• list_or_dict
• service_config_or_secret

[lionello]

If this is the right approach I can add "oneOf": [{"type": "null"}, {"type": "array": …}] to the remaining ones.

[lionello]

Some of these could possibly be list_of_unique_strings but that would technically be a breaking change.

[jhrotko]

they should get a warning from the IDE (if an extension is installed) or they get an error when running up for instance. The current behaviour is expected if environment or any other compose key is empty.

[lionello]

they should get a warning from the IDE (if an extension is installed) or they get an error when running up for instance. The current behaviour is expected if environment or any other compose key is empty.

That's right, you do get an error when you do up, but IMHO handling null is a better dev experience. Because arrays can be nil (and a nil array has length 0), the code already handles this.

[ndeloof]

I agree there's no reason we consider an null list as invalid while an empty one if fine