Difference in less compilation between php & nodejs library (grunt) with complicated calc expressions

[hostep]

Preconditions and environment

• Magento version 2.4-develop
• PHP 8.1 or 8.2
• Nodejs 16

Other things to prepare here:

1. Setup vanilla Magento install
2. Run the following:

$ cp package.json.sample package.json
$ cp Gruntfile.js.sample Gruntfile.js
$ npm install
$ bin/magento deploy:mode:set developer  # so that when compiling less via php, it's not being minified, so that comparing files is easier

3. In the backoffice, go to Stores >Attributes > Product, and for both news_from_date and news_to_date perform the following change:
   • Storefront Properties > Use in Search > Yes
   • Storefront Properties > Visible in Advanced Search > Yes

Steps to reproduce

1. First run the less compilation through the less library in php:

$ rm -R var/view_preprocessed/* pub/static/*
$ bin/magento setup:upgrade # needed to be able to visit frontend without js errors
$ bin/magento setup:static-content:deploy -f en_US

2. Now copy the resulting files in some other directory:

$ cp -r pub/static/ /tmp/magento-scd-comparison

3. In one tab in your browser, visit the frontend of the shop and click on Advanced Search in the footer and keep this open
4. Now run the less compilation through grunt (so via nodejs instead of php):

$ rm -R var/view_preprocessed/* pub/static/*
$ bin/magento setup:upgrade # needed to be able to visit frontend without js errors
$ grunt clean:luma && grunt exec:luma && grunt less:luma

5. Now compare the resulting files with the ones you copied before, I'm focusing here on something very specific (not all changes are relevant or important here):

$ diff -u /tmp/magento-scd-comparison/frontend/Magento/luma/en_US/css/styles-m.css pub/static/frontend/Magento/luma/en_US/css/styles-m.css  | grep -C3 calc

Output:

-.form.search.advanced .fields.range .field.date input,
-.form-giftregistry-edit .field.date input {
-  margin-right: 10px;
-  width: calc(100% - 33px);
+.form-giftregistry-search .fields-specific-options .datetime-picker {
+  margin-right: 10px;width: calc(100% - 23px + 10px);
 }
 .field .control._with-tooltip {
   position: relative;
 }
 .field .control._with-tooltip input {
-  margin-right: 10px;
-  width: calc(100% - 36px);
+  margin-right: 10px;width: calc(100% - 21px + 10px + 5px);
 }
 .checkout-index-index .modal-popup .field-tooltip .field-tooltip-content,
 .shipping-policy-block.field-tooltip .field-tooltip-content {

6. In a second tab in your browser, visit the frontend of the shop and click on Advanced Search in the footer and compare it to your first tab

Expected result

The width: calc expressions are the same between the PHP less library & nodejs less library:

less.js:
1. width: calc(100% - 23px + 10px);
2. width: calc(100% - 21px + 10px + 5px);

less.php:
1. width: calc(100% - 23px + 10px); or width: calc(100% - 13px);
2. width: calc(100% - 21px + 10px + 5px); or width: calc(100% - 6px);

Actual result

The width: calc expressions are different between the PHP less library & nodejs less library:

less.js:
1. width: calc(100% - 23px + 10px);   => simplified: width: calc(100% - 13px);
2. width: calc(100% - 21px + 10px + 5px); => simplified: width: calc(100% - 6px);

less.php:
1. width: calc(100% - 33px);
2. width: calc(100% - 36px);

How it looks with less.js:

How it looks with less.php:

Additional information

You may be surprised by the screenshots, but reading the original less code (which contains a bug), it should be rendered like the less.js result (the bug can be fixed by changing + @indent__s to - @indent__s which makes a lot more sense)

I've tried this again but with v4 of wikimedia/less.php (which is being used in Magento as php library to compile less, currently v3 is being installed). And v4 fixes this problem, I'm pretty much convinced this fixed it: wikimedia/less.php@5ca673d

Fix this by recognising calc() higher up as something that server-side LESS math should not be performed on in the first place.

So the solution for Magento is to switch from v3 to v4 of wikimedia/less.php. An additional benefit is that v4 is slightly faster than v3, about 1 second faster average when running bin/magento setup:static-content:deploy with all 3 default Magento themes.

I'm currently working on a PR that will upgrade wikimedia/less.php to v4, but it's more complicated, some less code in Magento is not written correctly (especially around those calc expressions) and we'll need to tweak it bit.
Expect a PR soon (maybe today, maybe later this week)

Release note

No response

Triage and priority

• Severity: S0 - Affects critical data or functionality and leaves users without workaround.
• Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

[m2-assistant]

Hi @hostep. Thank you for your report.
To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:

• @magento give me 2.4-develop instance - upcoming 2.4.x release
• For more details, review the Magento Contributor Assistant documentation.
• Add a comment to assign the issue: @magento I am working on this
• To learn more about issue processing workflow, refer to the Code Contributions.

---

Join Magento Community Engineering Slack and ask your questions in #github channel.
⚠️ According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.
🕙 You can find the schedule on the Magento Community Calendar page.
📞 The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

[github-jira-sync-bot]

Unfortunately, not enough information was provided to create a Jira ticket. Please make sure you added the following label(s): Reproduced on 2.4.x, ^Area:.*

Once all required labels are present, please add Issue: Confirmed label again.

[engcom-Dash]

@magento give me 2.4-develop instance

[magento-deployment-service]

Hi @engcom-Dash. Thank you for your request. I'm working on Magento instance for you.

[magento-deployment-service]

Hi @engcom-Dash, here is your Magento Instance: https://919f190ef565a01a8683042e4344fc83.instances-prod.magento-community.engineering
Admin access: https://919f190ef565a01a8683042e4344fc83.instances-prod.magento-community.engineering/admin_055b
Login: 8ca37304
Password: 68a9cad501f6

[m2-assistant]

Hi @engcom-November. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: 👇

• 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
• 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue.
• 3. Add Area: XXXXX label to the ticket, indicating the functional areas it may be related to.
• 4. Verify that the issue is reproducible on 2.4-develop branch
  Details

  - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!
• 5. Add label Issue: Confirmed once verification is complete.
• 6. Make sure that automatic system confirms that report has been added to the backlog.

[engcom-November]

Hello @hostep,

Thank you for the report and collaboration!

We were able to reproduced the issue on 2.4-develop.
Please take a look at the screenshot:

We have followed your steps, and it can be seen that width: calc expression are different for less js and less php.
Hence confirming the issue.

Thank you.

[github-jira-sync-bot]

❌ Something went wrong. Cannot create Jira issue.

[github-jira-sync-bot]

❌ Something went wrong. Cannot create Jira issue.

[github-jira-sync-bot]

✅ Jira issue https://jira.corp.adobe.com/browse/AC-9712 is successfully created for this GitHub issue.

[m2-assistant]

✅ Confirmed by @engcom-November. Thank you for verifying the issue.
Issue Available: @engcom-November, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.

[engcom-Bravo]

Hi @hostep,

Internal team has started to work on it.

Thanks.

[engcom-Bravo]

Hello,

As I can see this issue got fixed in the scope of the internal Jira ticket AC-9712 by the internal team
Related commits: b34c0a7

Based on the Jira ticket, the target version is 2.4.8-beta1.

Thanks