Magento2: Temando_Shipping maps and rewrites core js files even if not enabled as shipping method

[speedupmate]

Temando_Shipping extension that is included by default in Magento2 maps following paths in requirejs-config.js

var config = {
    paths: {
        temandoCheckoutFieldsDefinition: 'Temando_Shipping/js/model/fields-definition',
        temandoCustomerAddressRateProcessor: 'Temando_Shipping/js/model/shipping-rate-processor/customer-address',
        temandoNewAddressRateProcessor: 'Temando_Shipping/js/model/shipping-rate-processor/new-address',
        temandoShippingRatesValidator: 'Temando_Shipping/js/model/shipping-rates-validator/temando',
        temandoShippingRatesValidationRules: 'Temando_Shipping/js/model/shipping-rates-validation-rules/temando'
    },
    map: {
        'Magento_Checkout/js/model/shipping-rate-service': {
            'Magento_Checkout/js/model/shipping-rate-processor/customer-address' : 'temandoCustomerAddressRateProcessor',
            'Magento_Checkout/js/model/shipping-rate-processor/new-address' : 'temandoNewAddressRateProcessor'
        }
    }
};

this is included in all cases, if extension is configured to be actually used or just free-rides as a default enabled module after installation . So by purely existing in the system it affects core behaviour.

Preconditions

1. Magento 2.2.4 with demo data
2. Temando_Shipping extension enabled by default but not configured as shipping method

Steps to reproduce

1. On clean installation m2.2.4 with demo data
2. add stuff to cart and reach checkout
3. Temando_Shipping has mapped over some core js files even if not configured as a shipping method

Expected result

1. No inclusion of what so ever Temando_Shipping as it is not enabled as a shipping method and has no legit reason to affect core functionality
2. even if included it should not redefine core functionality if method is not configured

Actual result

1. Core js fiels are mapped and core behaviour is changed (how exactly it f*s up the defaults is currently not important)

ways to fix

1. use mixins instead mapping
2. since m2 lacks a way to tie requirejs-config rules to be applied/tied to additional configuration rules (by admin config values / layout rules) validate the need of a mixin inside each method affected inside mixin
3. if no legit need for affecting behaviour return a default behaviour

[marcelo-monteiro]

Hi @speedupmate
Like @okorshenko replied, in #17131, this issue is caused by a vendor extension. Please contact the vendor support team for the assistance:
https://developer.temando.com/soap/index.html or email them [email protected]

[speedupmate]

@marcelo-monteiro not sure if you can read and i'm probably rude but how do you expect vendors to fix core flaws in Magento 2 ?

So let me rephrase it: A core Magento 2 issue is that whenever you create a mixin or js mapping to rewrite a js file it is rewritten , replaced , extended even if module files extending it are not meant to be used.

[marcelo-monteiro]

@speedupmate, I got your point now. Well, could you please verify if this issue happens in the newest releases? I could not reproduce it, because I don't have access to versions with Temando. Thank you.

[magento-engcom-team]

Hi @marcelo-monteiro. 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: :point_down:

• [x] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
  Details

  If the issue has a valid description, the label G1 Passed will be added to the issue automatically. Please, edit issue description if needed, until label G1 Passed appears.

• [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add G2 Passed label to the issue by yourself.

• [ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [ ] 4. Verify that the issue is reproducible on 2.3-develop branch

  Details

  - Add the comment @magento-engcom-team give me 2.3-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.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. Verify that the issue is reproducible on 2.2-develop branch.

  Details

  - Add the comment @magento-engcom-team give me 2.2-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.2-develop branch, please add the label Reproduced on 2.2.x

• [ ] 6. Add label acknowledged once verification is complete.

• [ ] 7. Make sure that automatic system confirms that report is acknowledged.

[ishakhsuvarov]

@speedupmate

So let me rephrase it: A core Magento 2 issue is that whenever you create a mixin or js mapping to rewrite a js file it is rewritten , replaced , extended even if module files extending it are not meant to be used.

In this case it would be very helpful from your side to provide clear steps to reproduce not including any of the modules which are not present in this repository.

Please update description with clear steps to reproduce on the install with the core modules from this repository. Otherwise you may contact Temando Shipping team and report the issue with the module.

[peterjaap]

@ishakhsuvarov @magento-engcom-team @maksek @okorshenko we need to address issues like this. You can't just hand off responsibility for an extension just because its internal and not included in this repo. The composer meta package DOES include these external extension, therefore you bear responsibility for the integration tests.

Claiming its not your problem just because the code isn't in this issue is just sticking your head in the sand.

Or, which is even better, just completely remove all these extensions 90% of the people don't use from the composer metapackage and make all our lives a lot better.

This has happened before, with this Amazon issue; https://github.com/amzn/amazon-payments-magento-2-plugin/issues/274

[ishakhsuvarov]

@peterjaap Thank you for the input.

We have started working on setting up better flow for the issues related to bundled extensions which would allow us to pass on information to the vendors more quickly and efficiently. I expect this situation to start improving in the nearest future.

[speedupmate]

This issue is more general. Maybe its even a missing feature or undocumented feature.

Extensions usually have two enabling levels

1. bin/magento mo:en Module_Name
2. configuration level enable/disable. Most (but not all) will have and depend on some kind of extra enabling option and requiring additional configuration parameters from admin to work.

This issue mostly affects 2. level enabling schemas as whenever extension is enabled with 1. it does not usually mean that 2. is configured . However 1. is enough to enable mixins and path mappings to take effect even if 2. level is not configured/enabled.

In case of Temando_Shipping this is exactly what happens as it will map default checkout js overrides even if it is not used at all (and seen over ~500 live sites personally not one has ever used Temando on 2 level) . In this case all sites have flaws on checkout cause of this by default as part of functionality is just rewritten without no reason.

It does not shine in core modules as core modules are not meant to be disabled at all however this is a problem with all 3rd party extensions where those can affect the js behaviour even if not intended to be used but code is included in codebase.

One way to avoid this is to require 2. level check in all mixins so it would only rewrite core functionality when module is enabled and used (1 and 2 are met) . Or to require all extensions to define at least one admin level config option "enabled/disabled" if mixins or mappings are detected and depend on that to include the mixins mappings when this information is gathered.

[vtransy]

I got the same issue after update magento core from 2.2.3 to 2.2.6 for my project.

After investigate I see that it caused by pub/static/frontend not clean after update. I remove it manuals (del pub/static/frontend/*) then runs it again. All issues is resolved.

The cause i guest is requirejs-config.js is not clean up after I do setup:up command. Removes it manual should help you out in this case.

[magento-engcom-team]

@speedupmate, thank you for your report.

Unfortunately, we are archiving this ticket now as it did not get much attention from both Magento Community and Core developers for an extended period. This is done in an effort to create a quality, community-driven backlog which will allow us to allocate the required attention more easily.

Please feel free to comment, reopen or create new ticket according to the Issue reporting guidelines
if you are still facing this issue on the latest 2.3-develop branch. Thank you for collaboration.