[BUG] Running surface integration package from development folder not working

[dnmeid]

Make sure you're on the latest stable or beta build

• I have tested this on the latest stable or beta release

Is this a bug in companion itself or a module?

• I believe this to be a bug in companion and not a specific module

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I try to run a surface module from the development folder.
Using Companion v4.3.0+8937main-6ac3c16e89 on Windows 11.
I cloned the module, then yarn, then yarn package. I put the pkg folder from the tgz into the development folder.
Companion detects the dev module and I can switch in the surface integrations page to "dev" but the module doesn't start.

Log says: that the module @companion-surface/base/dist can't be found. (btw: this only shows up in the regular Companion log, not in the surface's debug log page).

When I manually add the node_modules folder with the according module to the module folder, the surface module starts and is working.
So I guess it is a packaging problem.

Steps To Reproduce

No response

Expected Behavior

Surface module packages should be able to run from a package with everything needed included in the package.

Environment (please complete the following information)

- OS:
- Browser:
- Companion Version:

Additional context

No response

[Julusian]

I think this broke for connection modules around the time of 4.0, and I haven't felt a reason to fix it.
Largely because if you have a packaged module, it can be imported through the ui instead.
In some ways I see this not working as a feature, as it stops users from blindly following old guides from 3.x on how to import a module when there is a far simpler approach of within the ui

But its a case of something in

companion/companion/lib/Instance/ModuleScanner.ts

Line 45 in 42a2dc4

async loadInfoForModule(fullpath: string, checkForPackaged: boolean): Promise<SomeModuleVersionInfo | undefined> {

needs to detect it as isPackaged: true, but I don't know what to use as the rule for that.

We can't really check for any particular file structure, as a packaged and unpacked module looks roughly the same structure.
Maybe we can check if there is a node_modules folder or not, but will that make it more confusing for users who don't know they need to do a yarn install?
We can't simply check the apiVersion in companion/manifest.json (like we used to). It changed to this because some devs had set that to something, and then companion was talking the wrong api version causing some 'bugs'.

I don't have any other ideas on how to reliably detect if the module is packaged or not. And I don't see a real need for this to work, so I simply haven't cared to look into actually fixing it