Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incompatibility with better roll tables module #40

Open
kakaroto opened this issue Nov 11, 2023 · 2 comments
Open

Incompatibility with better roll tables module #40

kakaroto opened this issue Nov 11, 2023 · 2 comments
Assignees

Comments

@kakaroto
Copy link
Contributor

A user reached out about the compendium library not working. After investigating the issue, it turns out to be caused by the "Better Roll Tables" module being loaded.
The reason for that is because that module apparently creates a exports global variable, which will cause every UMD dependency and build to fail, because it would cause the js umd packages to be installed under exports["pkg"] instead of window["pkg"] making those classes unavailable.
This is what happens when we open the compendium library, it loads the vue dependency component which then gets set in exports["ForgeCompendiumBrowserVue"] instead of being a global variable on window, causing this failure:
image
and this effect:
image

There's two actions to do here:
1 - report the issue to that module developer, because I'm sure it will be affecting potentially many other modules that may depend on build umd files or external dependencies
2 - perhaps modify dlopen so that it checks for a exports variable and renames it or keeps track of the variables in it so that when a dependency is loaded, it can copy the new fields into globalThis.window
Possibly do the same thing for the define method if it exists. See UMD format and how it loads dependencies:
https://jameshfisher.com/2020/10/04/what-are-umd-modules/

@ironmonk88
Copy link
Contributor

So further investigation is showing that it is indeed Better Rolltables that is causing the issue... but not intentionally. Nowhere in the code does it specify exports. And it works correctly on a stand alone version, this only seems to be affecting The Forge implementation.

In fact, exports exists within the code well before anything is even loaded, but then at some point on the stand alone version, gets deleted. It looks like on a Forge version, Better Rolltables is not allowing the exports to be deleted properly?

So I'm not entirely sure this is an issue specifically with Better Rolltables, and may be something more with how Foundry handles things.

@ironmonk88
Copy link
Contributor

On further investigation it looks like Sass is the culprit, and Better Rolltables uses Sass. Still unsure why this is an issue on Forge and not on local. And only affects Better Rolltables and not any of the other modules that use Sass.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants