Install EOS overlay by default

[Etaash-mathamsetty]

Enable the EOS overlay by default to fix some games from complaining about the overlay dlls being missing.

Will be testing shortly

Use the following Checklist if you have changed something on the Backend or Frontend:

• Tested the feature and it's working on a current and clean install.
• Tested the main App features and they are still working on a current and clean install. (Login, Install, Play, Uninstall, Move games, etc.)
• Created / Updated Tests (If necessary)
• Created / Updated documentation (If necessary)

[Etaash-mathamsetty]

im not sure why this constant legendaryConfigPath is not initialized, and im not sure how to fix it either. As far as I can tell it should be initialized already

[arielj]

im not sure why this constant legendaryConfigPath is not initialized, and im not sure how to fix it either. As far as I can tell it should be initialized already

the constants module is mocked for tests, you probably need to define that config in https://github.com/Heroic-Games-Launcher/HeroicGamesLauncher/blob/main/src/backend/__mocks__/constants.ts for the tests to work

[Etaash-mathamsetty]

im not sure why this constant legendaryConfigPath is not initialized, and im not sure how to fix it either. As far as I can tell it should be initialized already

the constants module is mocked for tests, you probably need to define that config in https://github.com/Heroic-Games-Launcher/HeroicGamesLauncher/blob/main/src/backend/__mocks__/constants.ts for the tests to work

it's not just the tests, I can't get regular old heroic to start either

[CommandMC]

You are introducing circular dependencies with this (basically, Vite can't figure out a way to correctly lay out the code).

Take this small example:

// a.ts
import { c } from './c'
export const a = 'a' + c

// b.ts
import { a } from './a'
export const b = 'b'

// c.ts
import { b } from './b'
export const c = 'c'

The c imported in a.ts will be undefined, since there's no way to arrange the files properly (in reality, Vite might notice that you're not using b in c.ts and thus drop the import, but you get the idea)

You now have two options (well, technically 3, but the third one really isn't practical):

1. Move the constants defined in eos_overlay.ts out of the global scope and into a function definition

const getEosOverlayConstants = () => ({
  currentVersionPath: ...,
  installedVersionPath: ...,
  // ...
})

2. Move the constants from eos_overlay.ts into constants.ts
   I wouldn't recommend this, as they are really only relevant for the EOS overlay functions
3. Untangle our dependency spaghetti
   This would involve removing as many imports as possible from constants.ts, possibly moving functions into other files, and generally reworking our "we have one file for all constants" model. Suffice it to say, I wouldn't recommend this either, but it is the direction we have to go if we want to avoid this spontaneous combustion in the future

[Etaash-mathamsetty]

You are introducing circular dependencies with this (basically, Vite can't figure out a way to correctly lay out the code).

Take this small example:

// a.ts
import { c } from './c'
export const a = 'a' + c

// b.ts
import { a } from './a'
export const b = 'b'

// c.ts
import { b } from './b'
export const c = 'c'

The c imported in a.ts will be undefined, since there's no way to arrange the files properly (in reality, Vite might notice that you're not using b in c.ts and thus drop the import, but you get the idea)

You now have two options (well, technically 3, but the third one really isn't practical):

1. Move the constants defined in `eos_overlay.ts` out of the global scope and into a function definition

const getEosOverlayConstants = () => ({
  currentVersionPath: ...,
  installedVersionPath: ...,
  // ...
})

2. Move the constants from `eos_overlay.ts` into `constants.ts`
   I wouldn't recommend this, as they are really only relevant for the EOS overlay functions

3. Untangle our dependency spaghetti
   This would involve removing as many imports as possible from `constants.ts`, possibly moving functions into other files, and generally reworking our "we have one file for all constants" model. Suffice it to say, I wouldn't recommend this either, but it is the direction we have to go if we want to avoid this spontaneous combustion in the future

thanks for the advice :)

[Etaash-mathamsetty]

ok now after my last bug fix to make sure it only enables only if it's disabled breaks legendary and the apps can't get the account id

[Etaash-mathamsetty]

I guess ill just revert that change for now.
edit: Seems like I hit the rate limit or something

[arielj]

Looks good to me, and works as expected from my tests.