Skip to content

[Bundle Split] Configuration loading #821

@Vincz

Description

@Vincz

So, I started to work on the isolation of the configuration process.
The result will be 4 additional bundles:

  • GraphQLConfigurationXmlBundle
  • GraphQLConfigurationYamlBundle
  • GraphQLConfigurationGraphQLBundle
  • GraphQLConfigurationMetadataBundle

The configuration generation would no longer be part of the Dependency Injection / Container builder process (ie. Removal of ConfigParserPass) but will be a regular service (used by the TypeGenerator).
The main advantages is that the configuration processing will be a regular service and we will be able to extend it, easily add features, remove all static classes, etc...
You can have a look at the bundles here https://github.com/Vincz/graphql-bundles
And at the modified main bundle here: https://github.com/Vincz/GraphQLBundle/tree/config-generator

The "problems" I'm facing are the following:

  1. The namespaces are really long, like for example: Overblog\GraphQL\Bundle\ConfigurationMetadataBundle\Transformer\ArgumentsTranformer
  2. The mapping configuration would now be set in the sub bundles configuration, like:
overblog_graphql_configuration_yaml:
    mapping_directories: 
        - "%kernel.project_dir%/config/types"
        - "%kernel.project_dir%/config/queries"
        - "%kernel.project_dir%/config/mutations
  1. We have to duplicate the tests, phpstan, phpcs, CI config for each bundle instead of only in the main one (unless we could do that in a main root repositories with different packages? I see this a lot in the Javascript world but not so much in PHP. Example in JS: https://github.com/mui-org/material-ui).
  2. The namespace of annotations would change from Overblog\GraphQLBundle\Annotation to Overblog\GraphQL\Bundle\ConfigurationMetadataBundle\Metadata (as now both annotations and attributes are supported with the same classes, and will be even more when Default property with @NamedArgumentConstructor doctrine/annotations#402 will be publish).

It's not really "problems", it's more like consequences of the split.
Let me know what you think.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions