Unable to use `if-then-else` syntax at root level in json-schema of envs

[dibericky]

The feauture or bug you are proposing

User should be able to use if-then-else, oneOf, anyOf at root level of json-schema.

The description of the bug or the rationale of your proposal

Since here the library makes a trasformation of the json-schema user defined, any if-then-else, oneOf, anyOf ecc the user used are gonna be lost and the applied json-schema to the environment variable will be something different from what user expected.

A snippet of code for replicating the issue or showing the proposal usage if applicable

Pass the following json-schema to the library:

{
  type: 'object',
  required: [],
  if: {
    properties: {
      FLAG: { type: 'boolean', const: true}
    }
  },
  then: {
      required: [
        'BAR'
      ],
      properties: {
        FLAG: { type: 'boolean', const: true},
        BAR: { type: 'string' }
      }
    },
    else: {
      required: [
        'FOO'
      ],
      properties: {
        FLAG: { type: 'boolean', const: false},
        FOO: { type: 'string' }
      }
    }
}

The resulting json-schema applied to the envs is gonna be this:

{
  "type": "object",
  "required": [
    "USERID_HEADER_KEY",
    "GROUPS_HEADER_KEY",
    "CLIENTTYPE_HEADER_KEY",
    "BACKOFFICE_HEADER_KEY",
    "MICROSERVICE_GATEWAY_SERVICE_NAME"
  ],
  "properties": {
    "USERID_HEADER_KEY": {
      "type": "string",
      "description": "the header key to get the user id",
      "minLength": 1
    },
    "USER_PROPERTIES_HEADER_KEY": {
      "type": "string",
      "description": "the header key to get the user permissions",
      "minLength": 1,
      "default": "miauserproperties"
    },
    "GROUPS_HEADER_KEY": {
      "type": "string",
      "description": "the header key to get the groups comma separated list",
      "minLength": 1
    },
    "CLIENTTYPE_HEADER_KEY": {
      "type": "string",
      "description": "the header key to get the client type",
      "minLength": 1
    },
    "BACKOFFICE_HEADER_KEY": {
      "type": "string",
      "description": "the header key to get if the request is from backoffice (any truly string is true!!!)",
      "minLength": 1
    },
    "MICROSERVICE_GATEWAY_SERVICE_NAME": {
      "type": "string",
      "description": "the service name of the microservice gateway",
      "pattern": "^(?=.{1,253}.?$)[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?(?:.[a-z0-9](?:[-0-9a-z]{0,61}[0-9a-z])?)*.?$"
    },
    "ADDITIONAL_HEADERS_TO_PROXY": {
      "type": "string",
      "default": "",
      "description": "comma separated list of additional headers to proxy"
    }
  },
  "additionalProperties": false
}

even though user defined something different.

The expected result for your bug

The schema applied to the envs should be what users define. If adding baseEnvs is strictly necessary, then they should be merged properly based on the structure of the users defined schema.
The best practice, in my opinion, should be that the library exports the base schema and users should handle them by hand.

Your environment

node: v14.19.3

custom-plugin-lib: v4.2.0

os: Ubuntu 20.04 LTS

[danibix95]

Hi, is there any news about this bug?

[davidebianchi]

Hi, no we have not worked on it. The complex think is to merge the default required env schema, that if env are not object could not be easy.
We could improve and add the env in all the if-then-else block, which must contains an object. But it is not a true resolution of the base problem