{"id":110,"date":"2023-10-21T15:09:48","date_gmt":"2023-10-21T19:09:48","guid":{"rendered":"https:\/\/kimsal.com\/blog\/?p=110"},"modified":"2023-10-21T15:09:48","modified_gmt":"2023-10-21T19:09:48","slug":"php-assert-not-working-in-laravel-with-sail","status":"publish","type":"post","link":"https:\/\/kimsal.com\/blog\/2023\/10\/21\/php-assert-not-working-in-laravel-with-sail\/","title":{"rendered":"PHP assert not working in Laravel with Sail?"},"content":{"rendered":"\n<p>Recently, I hit a weird &#8216;bug&#8217;.  <\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&lt;?php\n...\n$file = ReportService::generateReport(4);\nassert(file_exists($file));\n... \n\/\/ do more stuff<\/code><\/pre>\n\n\n\n<p>The $file was not being created, so I&#8217;d added a quick &#8216;assert&#8217; in the code, and&#8230; file_exists($file) was indeed false (checked when stepping through debugger), but assert was not stopping\/failing.<\/p>\n\n\n\n<p>But&#8230; running a simple assert from command line was working.  This was something different only when running under the Laravel Sail docker setup.  I dug in a bit more&#8230;<\/p>\n\n\n\n<p>The Laravel Sail system is a convenient way to run a local dev environment using a pre-defined  docker compose configuration. At heart, the docker compose system is pulling from a current ubuntu and grabbing PHP packages from ppa-ondrej. Those packages, however, are configured for production, and &#8230; I don&#8217;t know when this happened, but the basic &#8216;assert&#8217; function in PHP somehow got extended with a bunch of ini-based configuration stuff, meaning what used to be a basic understandable function now has &#8230; many ways to not work as expected (well, my earlier expectations, at any rate).<\/p>\n\n\n\n<p>If you&#8217;ve not published the sail assets yet, run<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>artisan sail:publish<\/code><\/pre>\n\n\n\n<p>This will put specific PHP versions and Dockerfile configs in \/docker folder.<\/p>\n\n\n\n<p>In which PHP version you&#8217;re using, find the php.ini file and add a line under the [PHP] section with &#8216;zend.assertions=1&#8217;.  The &#8216;default&#8217; for zend.assertions is &#8216;1&#8217;, but the production PHP packages must be setting it to -1 (for production, which sort of makes sense?)<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;PHP]\npost_max_size = 100M\nupload_max_filesize = 100M\nvariables_order = EGPCS\nzend.assertions = 1<\/code><\/pre>\n\n\n\n<p>Then rebuild the sail container (.\/vendor\/bin\/sail build &#8211;no-cache)<\/p>\n\n\n\n<p>This will set the zend.assertions to &#8216;1&#8217; which is the development mode behaviour.  This is more appropriate for sail, which is intended as a development platform, not production.<\/p>\n\n\n\n<p>The behaviour of &#8216;<a href=\"https:\/\/www.php.net\/assert\" data-type=\"link\" data-id=\"https:\/\/www.php.net\/assert\">assert<\/a>&#8216; has grown a lot over the years, and I&#8217;ve not kept up with any of that (which shows how often I use it!).   The &#8216;<a href=\"https:\/\/www.php.net\/manual\/en\/ini.core.php#ini.zend.assertions\">zend.assertions<\/a>&#8216; ini setting is useful, but I don&#8217;t know when it was added.<\/p>\n\n\n\n<p><\/p>\n\n\n\n<p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Recently, I hit a weird &#8216;bug&#8217;. The $file was not being created, so I&#8217;d added a quick &#8216;assert&#8217; in the code, and&#8230; file_exists($file) was indeed false (checked when stepping through debugger), but assert was not stopping\/failing. But&#8230; running a simple assert from command line was working. This was something different only when running under the&#8230;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-110","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/kimsal.com\/blog\/wp-json\/wp\/v2\/posts\/110","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/kimsal.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kimsal.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kimsal.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/kimsal.com\/blog\/wp-json\/wp\/v2\/comments?post=110"}],"version-history":[{"count":0,"href":"https:\/\/kimsal.com\/blog\/wp-json\/wp\/v2\/posts\/110\/revisions"}],"wp:attachment":[{"href":"https:\/\/kimsal.com\/blog\/wp-json\/wp\/v2\/media?parent=110"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kimsal.com\/blog\/wp-json\/wp\/v2\/categories?post=110"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kimsal.com\/blog\/wp-json\/wp\/v2\/tags?post=110"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}