I figured it out myself. Here is what if have done:

1. Create a service_dev.yml with the following content:

services:
    # This part is important!
    _defaults:
        autowire: true
        autoconfigure: true
        public: false

    # Use the namespace where your fixtures are
    AppBundle\Development\DataFixtures\:
        resource: '../../src/AppBundle/Development/DataFixtures'

2. Import it into config_dev.yml
3. In your services.yml exclude the fixture folder:

services:
    AppBundle\:
        exclude: '../../src/AppBundle/{Entity,Repository,Tests,Development}'

After these changes you can have this bundle as a dev dependency and run composer install --optimize-autoloader --no-dev without an error.

Thanks for posting your fix! There must be a nicer way to handle this.

There must be a nicer way to handle this.

In general, if you only require this bundle as part of your dev dependencies, you should only create the appropriate services if the bundle is present. In this case, the service is generated due to the default config (which creates a service for every class it finds).

What confuses me is that the services are private and removed from the cached container if not used (which they shouldn't be in this case), so the service shouldn't be instantiated. Could you maybe get a trace for the original error or figure out what causes a fixture service to be instantiated?

Ah, I just got more info about this error.

@alcaeus you're understanding is correct. However, the error comes earlier: when services.yml is being parsed. The service auto-registration code in Symfony tries to open CustomAbstractFixture so that it can make it a candidate to be a service. But it fails immediately because the parent class isn't found.

I think affects any project using DoctrineFixturesBundle as a dev dependency and deploying with --no-dev. But I don't think the fix is here in this bundle (the workaround listed above is great, btw, but it should be simpler). I've created an issue on Symfony symfony/symfony#25929

@weaverryan Thanks for investigating! Solving this in the container makes sense!

Reverted changes suggested by @fabwu and upgraded to 3.4.4 and the problem looks like it's gone.

bug #25932 Don't stop PSR-4 service discovery if a parent class is missing (@derrabus)

This issue came back on Symfony 4 with flex.

This issue came back on Symfony 4 with flex.

It's an issue in Symfony - nothing we can do here. Please report it there.