Make packages reference each other more cleanly

[Pandapip1]

This makes each component reference other components' files by name (the proper way) rather than by a path outside of the package. Untested; I'm not quite sure how to test this.

[Pandapip1]

act -W .github/workflows/unitTests.yml -P ubuntu-latest=ghcr.io/catthehacker/ubuntu:act-latest says all tests pass.

| Test Suites: 7 passed, 7 total
| Tests:       1 skipped, 97 passed, 98 total
| Snapshots:   0 total
| Time:        12.486 s

[abulojoshua1]

Hi @Pandapip1, I’d like to propose replacing the current local dependency with a module alias approach (e.g. using module-alias) so we can reference shared paths more flexibly.

Right now, file:../Common treats Common as a standalone package, which works, but it’s a bit rigid and requires maintaining a dedicated dependency just for that directory. If we instead define aliases at the project level, we can reference both Common and other root-level paths in a consistent way without needing separate entries for each.

For example:

"_moduleAliases": {
  "@": "./src",
  "common": "../Common"
}

This would allow imports like:

require('common/utils');
require('@/components/Button');

The main advantages:

• Avoids managing a special-case dependency for Common
• Makes it easy to alias additional root-level paths as needed
• Keeps import paths cleaner and more consistent across the project
• Reduces coupling between repos if the structure changes

This keeps things simpler at the application level while still giving us flexibility in how we organize shared code.

On performance: module-alias introduces only a very small overhead during module resolution at startup and when resolving aliased imports. This is generally negligible in typical Node.js applications and shouldn’t have any noticeable impact on runtime performance.

If this were a TypeScript project, an even better option would likely be using "compilerOptions.paths"(with an appropriate runtime/bundler resolver) since it provides cleaner alias management at the project level without relying on a runtime patch like module-alias. That would give us the same import-path flexibility in a more native way for a TS codebase.

For example:

{
    "compilerOptions": {
        "paths":  {
           "@/*": ["./src/*"]
        },
    }
}

[Pandapip1]

It's been a while since I've done any significant NodeJS stuff. If you feel that this is a better approach, I've got "Allow edits by maintainers" selected so you should be able push to it.

That being said, each of those directories has its own package.json, since they are actually (other than the previous directory traversal nonsense) completely standalone NodeJS packages. That's why I added them as dependencies to each other; this is IMO probably what the original OnlyOffice people had intended to do.