scratch that - no idea, I delete EVERYTHING and start again (for the 4th time today) and it works now :(

Is this the issue of having a stale ?
libriaries/autoload_psr4.php

that needs to be deleted thus it gets auto-created ?

Is there a simple way to detect the need to recreate file ?
libraries/autoload_psr4.php

A check that will have no performance cost
Compare modification timestamps of only 2 files

The modification time of libriaries/autoload_psr4.php
and modification time of a file NNN.something whose modification time changes
when we update our local repository ?
or when we run composer install ?
or when we run npm install ?

Is it legitimate change that the file is deleted when we run npm install ?

No idea - I deleted EVERYTHING and did it all again and it was fine.

No we are not going to get into a process of trying to dynamically decide whether it needs to be recreated otherwise we might as well not have the file at all and have the performance penalty of processing its data on every request. Or, ya know, just abandon being able to autoload our extension PHP files.

I had assumed a git pull, git reset --hard, composer install, npm install - was enough to "clean" everything - but it appears it is not :(

Nope. Local environment files aren't going to be deleted in that process, i.e. configuration.php or libraries/autoload_psr4.php.

The one thing I might suggest is OK is if you're running the install app, check for presence and delete if it exists. Otherwise, any type of dynamic "check if needs to be recompiled" is going to create a major performance penalty for every request.

yeah I get the configuration.php would not be touched, but I did not know about libraries/autoload_psr4.php and as its in .gitignore it was not showing up in git status

Now I know - thank you.

The modification time of libriaries/autoload_psr4.php
and modification time of a file NNN.something whose modification time changes
when we update our local repository ?
or when we run composer install ?
or when we run npm install ?

Is it legitimate change that the file is deleted when we run npm install ?

The libraries/autoload_psr4.php file only requires being regenerated when your extensions change. Not when a composer install happens, not when any npm command is run.

@mbabker

The libraries/autoload_psr4.php file only requires being regenerated when your extensions change. Not when a composer install happens, not when any npm command is run.

ok, thanks for information,

About the cost of doing it via modification times
The 2 file modification times (metadata of the filesystem) of 2 files and a PHP comparison of them compare to numerous file loading and file_exists checks in the CMS during every page load is by comparison an almost zero time, measured not in millseconds but in microseconds since filemtime() returns cached value (and in our case we do not need to clear any filesystem cache)
that is why i made the question.

Because of course it is redundant in production, i agree it was a bad idea

@mbabker

i understand that
npm install is not related to libraries/autoload_psr4.php

My question was not about being related,
but if it is "ok" to include deletion of the file in the nodejs scripts, thus production sites will not be effected at all

because only a tester will ever run npm install

No, deleting this file should not be tied to a composer or npm operation. Because the ONLY time it is required to regenerate that file is when your extensions change (install/uninstall/enable/disable).

Regenerating the UI assets or the contents of the libraries/vendor directory has NOTHING to do with the validity of the libraries/autoload_psr4.php file.

personally all these "non standard things" a developer needs to do just to get a PHP app working is confusing even for experienced developers. :-)

I have a doEverything.sh file now that contains all these commands - its hard enough having to remember my own projects build command lets alone a million others :)

Plus this page https://docs.joomla.org/Special:MyLanguage/J4.x:Setting_Up_Your_Local_Environment is REALLY hard to find !

@mbabker

i understand your arguments i did not say otherwise,
i was just thinking options for making life of testers easier, so this idea is not good either,
may be then add something to the docs

@PhilETaylor

Plus this page https://docs.joomla.org/Special:MyLanguage/J4.x:Setting_Up_Your_Local_Environment is REALLY hard to find !

thanks, i was trying to find it (again), i remember it was somewhere, wanted to check it out if i missed information last time i read it

I think, once J4 stabilises, this issue will be gone. Currently we get it because core classes are getting namespaced. So that file needs to be regenerated along with it.

Plus this page https://docs.joomla.org/Special:MyLanguage/J4.x:Setting_Up_Your_Local_Environment is REALLY hard to find !

Since yesterday or so it is linked in the readme ?

I think, once J4 stabilises, this issue will be gone. Currently we get it because core classes are getting namespaced. So that file needs to be regenerated along with it.

Agreed.

Since yesterday or so it is linked in the readme ?

Thanks. Google doesnt have it much at the moment, and all the old links go to crazy articles like https://docs.joomla.org/Setting_up_your_workstation_for_Joomla_development

Since yesterday or so it is linked in the readme ?

George merged it yesterday because I pointed out how hard it was to find and added the link to the readme at the same time. He also spent some time deleting some of the old content that related to svn etc