Update override-existing-javascript.md

[Nico-Schaefer-2111]

• add note for overriding async JS-Plugin

[JoshuaBehrens]

@aragon999

[aragon999]

Thank you, but I think this is not an ideal solution, as the path depends on how the plugin is installed, and it is not always possible to know how a plugin is installed, for example when one has a store plugin, which extends another store plugin.

I tried to configure the one plugin as webpack path, to import it not via the relative path, but I did not manage to get it working. I will have a closer look into that when I am back from my holidays.

[Nico-Schaefer-2111]

@aragon999 thanks, this kind of implementation is triggering me either. But I couldn't find another solution for this.

[tobiasberge]

Hi, sorry for my late reply. I agree that this solution is not looking nice with the ugly path.

I think the problem is, that the prior example with getPlugin('PluginName') and then get('class') will not give you the class itself if it is async, because it was not downloaded yet.

Because the PluginManager.override() with the override-plugin containing the get('class') is happening BEFORE initializePlugins() which is downloading the plugins in the first place. For core plugins this is not a problem because everyone is likely just using the alias src/ to directly import it statically.

A webpack alias could be an alternative to avoid the path at least in the code. But like @aragon999 already said this can be tricky to determine the actual path. And it also requires a custom webpack config which was not needed before. We could try to automatically generate an alias for each bundle inside the core webpack config so that you have always something like @MyExtension1/something, @AnotherExtension2/something available.

Or solving it on a programmatic level, that we have something like fetchPlugin('MyAsyncPlugin') to force download a plugin before the actual initializePlugins so you are able to get the class for overriding it. But not sure honestly about the side-effects and drawbacks right of the bat without further testing.

[Isengo1989]

Hi, sorry for my late reply. I agree that this solution is not looking nice with the ugly path.

I think the problem is, that the prior example with getPlugin('PluginName') and then get('class') will not give you the class itself if it is async, because it was not downloaded yet.

Because the PluginManager.override() with the override-plugin containing the get('class') is happening BEFORE initializePlugins() which is downloading the plugins in the first place. For core plugins this is not a problem because everyone is likely just using the alias src/ to directly import it statically.

A webpack alias could be an alternative to avoid the path at least in the code. But like @aragon999 already said this can be tricky to determine the actual path. And it also requires a custom webpack config which was not needed before. We could try to automatically generate an alias for each bundle inside the core webpack config so that you have always something like @MyExtension1/something, @AnotherExtension2/something available.

Or solving it on a programmatic level, that we have something like fetchPlugin('MyAsyncPlugin') to force download a plugin before the actual initializePlugins so you are able to get the class for overriding it. But not sure honestly about the side-effects and drawbacks right of the bat without further testing.

Maybe it is better suited here then? -> https://github.com/shopware/shopware/discussions

As for helping developers till then, what about a more generic info, like: "For async plugins you need to import it via an absolute path where your plugin is located" (since it could also be located in custom/plugins etc.)