Shim being loaded as a script is an issue about kanka-foundry HOT 3 CLOSED

🎉 This issue has been resolved in version 2.3.5 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

from kanka-foundry.

The problem is that this file is loaded as scripts, rather than esmodules. As such, it is running in global scope, and the libWrapper symbol it creates will be visible by every other module, even though it is not the full library.

While the shim will check for libWrapper.is_fallback before using it, many modules that do not use the shim might not, and as such this might actually cause modules to believe the library is installed when it is not.

In addition, if more than one module does this, it is unknown which module will run later and thus which shim will "win out". As such, you cannot predict which implementation the shim has. It is possible another module would run after yours with an older version of the shim that does not support something you rely on, or that is missing bugfixes, breaking your module.

These reasons are why the libWrapper documentation states in bold:

Please do not make your custom shim available in the global scope.

It is also why the default shim exports libWrapper, rather than assigning it to global scope. You removed all this from your shim.

I would ask that you change this whenever possible so that this file is imported, rather than loading it in global scope as a script. It is better for your module, and also for other modules.

from kanka-foundry.

Thanks for letting me know, looking at the discord there seems to have been a bit of confusion around this issue in this regard.

Well, I didn't want to update this package to use the new (soon to be released) sheet registrar lib until I actually had a bug or feature to release with it... I guess I have a bug fix on my hands now ;)

I'll fix this as soon as I can, hopefully (but not quite guaranteed) sometime tonight (CEST).

from kanka-foundry.