GraphQL 4: Generated code poisons IDE search

[unclecheese]

Because most types are based on models, it's really common that the generated type classes have the same short name as the DataObject implementations in the project code. This can be super annoying when searching for something like Page, because often times the IDE prioritises the generated graphql code class.

Proposed solution: Confuse the IDE

We'll never be able to fully remove "Page" from the generated code without handicapping the debugging experience, but what we can do is dirty it to make it less appealing to the IDE.

Because we're not relying on PSR-4 (everything is just require_once() in a bespoke function call), we can get away with some nonconventional stuff, here.

.graphql/default/Page.php

class <?= md5('Page') ?> extends ObjectType

Then just update AbstractTypeRegistry::fromCache():

                $cls = static::getSourceNamespace() . '\\' . md5($typename);

You'd probably still see it, but at least it wouldn't be ranked higher than your actual PSR-4 compliant Page class.

[unclecheese]

@ScopeyNZ Has raised the idea of using a phar, which would definitely clean up the IDE, but would severely compromise debugability of the generated code.

[michalkleiner]

If it was controlled by a separate ENV variable whether it produces a phar or standard code, phar being the default. Then for debugging you can switch it around as/when needed.

[unclecheese]

Yeah, good point.. how about:

interface ClassNameObfuscator
{
  public function obfuscateClassname(string $class): string;
}

Implementations:

• NaiveClassNameObfuscator (debug mode -> return $class;)
• HashObfuscator (non-debug mode -> return md5($class);)
• HybridObfuscator (middle ground, if you don't want to bother changing env vars -> return sprintf('%s_%s', $hash, $class);

Config:

---
only:
  envvarset: 'DEBUG_SCHEMA'
---
SilverStripe\Core\Injector\Injector:
  SilverStripe\GraphQL\Interfaces\ClassNameObfuscator:
    class: SilverStripe\GraphQL\Services\NaiveClassNameObfuscator
---
only:
  envvarset: 'ANOTHER_VAR_HERE'
---
# different implementation... etc

[unclecheese]

PR is up here: #426

[unclecheese]

Merged