I would assume we have this issue in all 5.x and 6.x branches. Not sure if we also have it already in 4.4-dev.

I'm almost sure @dgrammatiko can tell us where to look for the issue cause. Should be something which happens only when running build.php but not when doing just composer installand npm ci.

I think it happens only with the minified versions of the css files.

Yes the minifier strips ALL comments

That needs to be changed then as we MUST not remove the copyright notices!!

We might be able to add them back to the minified css files after they have been removed by the minifier.

minified files are generated with copyright headers when you run npm ci so I have no idea why the build script is set to remove them. I cant stress enough how bad it is for Joomla to remove the copyright notices

Sure we should fix that, but that should not stop my other PR for the dependency updates.

The contents of the media folder after a checkout and npm and the contents in a zipped release should be identical. They're not, and not just the missing copyright

This step in the build script seems to make the difference, as the licence information is also removed from the non-minified CSS files.

If you comment out this step, they will remain intact. @dgrammatiko

As already mentioned here, the licence is removed from the minified files beforehand.

Yes the minifier strips ALL comments

Oh, that’s different than the minifier this lightningcss plugin (I wrote it) is versioning any url based entries. Unfortunately, lightningcss is the problem here. Maybe roll back to postcss (we have the plugin also there)

whatever is done PLEASE ensure that we end up with the build script creating identical files as are created locally with npm i

its not just the comments that are wrong but also element ordering

Sone differences we currently also have between consecutive runs of npm ci or consecutive package buils.

Sone differences we currently also have between consecutive runs of npm ci or consecutive package buils.

such as?

The principle of reprodicable builds is that they are always the same

E.g. ordering of assets in diverse joomla-assets-json files. That seems to depend on the asynchronous processing of npm ci or npm install as such.

Sure it would be extremely helpful to have always the same result.

Oh, that’s different than the minifier this lightningcss plugin (I wrote it) is versioning any url based entries. Unfortunately, lightningcss is the problem here. Maybe roll back to postcss (we have the plugin also there)

@dgrammatiko do you mean only roll back this change #42427, or completely roll back to postcss?

At the moment, I can't think of any reason why we shouldn't just call npm ci instead of `npm install in the build script.

Is --unsafe-perm still available at all?

Why does node build/build.mjs --cssversioning modifies existing css/js file when it just should calculate the hash? tries to insert backdoor?

I see now, it is looking for embed url()

Why does node build/build.mjs --cssversioning modifies existing css/js file when it just should calculate the hash? tries to insert backdoor?

I see now, it is looking for embed url()

And I think it also "fixes" our UTF8 issue, that we had.
But this was also before the switch to lightningcss.

At the moment, I can't think of any reason why we shouldn't just call npm ci instead of `npm install in the build script.

joomla-cms/build/build.php

I think we definitely should change that to npm ci.

Is --unsafe-perm still available at all?

I think we should remove that: npm/cli#2196

P.S.: I think the reason why we sill have npm install and not npm ci in the build.php is because on older npm versions npm ci was not supported. That was the reason for Joomla 4, and later it was just overlooked. But we are safe to change it now in 5 and 6 as we require suitable node and npm versions.

It seems problem happen because css transfrom() running twice (first with build and second with versioning) and get confused with the comments.
For example bootstrap-grid.css stay intact but comments from bootstrap.css are removed (at least in my test).

Maybe if we can integrate versioning (css versioning) in to first run (with build), then it should be okau.
In theory.

Interesting find @Fedik , but in the minified version, we probably won't be able to solve it with Lightningcss so that the lincence comment is not deleted.
At least, I haven't found a way to do so yet.
I think it's then a question of deciding whether to roll back completely to PostCSS or whether it's somehow feasible.

The same for minified version.
Lightningcss keep comments like /*! ... */. But seems only when it is at begining of the file (or a line), or something like that, I did not found a good explanation.

@LadySolveig For changing the npm install to npm ci in the build.php script: Do you want to make a PR as it was your finding?

Not really urgent as it should work like before (if package.json and package-lock.json are in synch, what always should be the case on a clean branch), but nice to have.

But if you don't have the time, I can make a PR.

The same for minified version. Lightningcss keep comments like /*! ... */. But seems only when it is at begining of the file (or a line), or something like that, I did not found a good explanation.

Yes, lightningcss removes it only when at the beginning of the complete file, see comment here: parcel-bundler/lightningcss#43 (comment)

The problem seems to come from the fact that we add the @charset "UTF-8"; to the top of the file before the initial copyright comment, so with the 2nd run for the versioning that comment is not at the beginning of the file anymore and so is removed.

P.S.: The @charset "UTF-8"; addition was added with this PR into 4.4-dev and later merged up: #42938

P.P.S.: Ah, not merged up 1 to 1 into 5, but in 5..1-dev it was made with PR #43207 .

Will create a PR and try to fix both. Thank you all for the teamwork and the reporting.