[Bug]: Generated PHP Files Emit Deprecated/Warn Errors that Break the Plugin

[dac514]

Extension Version

1.2.1

PHP Binary

Sail

Operating System

Linux

What happened?

I'm encountering issues similar to #485, where the plugin fails to parse PHP files it generates itself. The failures seem related to deprecated messages and warnings from third-party packages that end up appearing in the plugin output and cause it to break.

Environment Details

• PHP Version: 8.4.14 CLI
• PHP INI settings:
  • display_errors = Off
  • log_errors = On
  • error_log = <not set> (defaults to SAPI error logger → stderr in CLI)

Steps to Reproduce

1. Use the plugin to generate a PHP file (e.g., _laravel_ide/discover-*.php).
2. Look at VS Code error logs.

Observed Output

When plugin/php runs the generated files, output is polluted by deprecated messages like:

2025-11-16 15:19:01.567 [error] "/usr/bin/php" "/home/dac/code/github/my/project/vendor/_laravel_ide/discover-739c51cbd2b78369222c3575c94c5ee8.php"
2025-11-16 15:19:01.567 [error] Translations
PHP Deprecated: Osiset\ShopifyApp\Util::parseQueryString(): Implicitly marking parameter $delimiter as nullable is deprecated, the explicit nullable type must be used instead in /home/dac/code/github/my/project/vendor/kyon147/laravel-shopify/src/Util.php on line 68

Even though these messages are non-fatal and come from third-party code (outside my control), they disrupt plugin.

Investigation

I think the discover files are generated from these template files:

• php-templates/bootstrap-laravel.php
• src/templates/bootstrap-laravel.ts

At the top of these PHP templates, error_reporting(E_ERROR | E_PARSE); is set, which controls what is shown by display_errors but does not affect log_errors.

Since PHP CLI logs are sent to stderr (unlike web server configurations such as Apache, where logs are typically written to a file), this behavior can make the plugin brittle and more susceptible to issues caused by noisy output.

Running the generated file like:
/usr/bin/php "/home/dac/code/github/my/project/vendor/_laravel_ide/discover-739c51cbd2b78369222c3575c94c5ee8.php" 2>/dev/null
prevents these non-critical messages from appearing in the output. Not sure if that's a solution, just giving an example with 2>/dev/null

Maybe another solution is to manually set error_log to some path but that's not the PHP CLI default in most distros, Dockerfiles, it's a cumbersome step.

[N1ebieski]

I can't reproduce this bug. Even though I create a fake file with:

<?php

namespace App;

error_reporting(E_ALL);

class Util
{
    public static function parseQueryString(string $query, string $delimiter = null)
    {
        return $query . $delimiter;
    }
}

and run this method inside one of translation files:

<?php

error_reporting(E_ALL);

use App\Util;

return [

    'previous' => '&laquo; Previous',
    'next' => 'Next &raquo;',
    'test' => Util::parseQueryString('something'),

];

I still get output without any deprecated notice:

2025-11-16 22:12:18.312 [info] Activating Laravel Extension...
2025-11-16 22:12:18.312 [info] Started

If I run this file:

<?php

use App\Util;

Util::parseQueryString('something');

I get:

DEPRECATED  App\Util::parseQueryString(): Implicitly marking parameter $delimiter as nullable is deprecated, the explicit nullable type must be used instead in app/Util.php on line 9.

[dac514]

Hmm... I'm using VS Code on Fedora Linux with KDE. Here's the errors. Happens every time unless I change php.ini to something other than the defaults:

I'm using PHP CLI (sail, octane/frankenphp, etc, not to be confused with PHP when used by Apache, FPM, etc)

The defaults when installing 8.4 are display_errors = Off, log_errors = On, error_log = <not set>

Docs from the PHP manual.

error_log: Name of the file where script errors should be logged. The file should be writable by the web server's user. If the special value syslog is used, the errors are sent to the system logger instead. On Unix, this means syslog(3) and on Windows it means the event log. See also: syslog(). If this directive is not set, errors are sent to the SAPI error logger. For example, it is an error log in Apache or STDERR in CLI. See also error_log().

Are you perhaps a PHP that pipes errors somewhere else than STDERR?

[dac514]

For now I have made the problem go away by customizing my docker container with error_log = /tmp/php_errors.log