Consuming a package from a place outside of where it was generated results in typing errors.

[RickMeijer]

Describe the bug

I'm trying to make a ui-kit inside a monorepo, which should output in a shared folder after running npm run package
It sort of looks like this:

• shared
• Project A
• Project B
• ui-kit (Project C)

I want the ui-kit project to output inside the shared folder, which is done easily enough using kit.package. However: when the projects trying to consume this package, vscode throws a fit.
When the projects consume directly from ui-kit/package are aren't any problems, and I don't really understand why. I've tried messing about with tsconfig.json,

Reproduction

Example repo: https://github.com/RickMeijer/example-package-error

Setup

• package_internal: npm run package outputs in package_internal/package
• package_external: npm run package outputs to package_exported
• package_exported: see above. Result of running npm run package in package_external
• package_consumer: has both internal and external packages included

Reproduction steps:

Open package_consumer/src/routes/index.svelte in vscode, and bask in the error.

Logs

No response

System Info

System:
    OS: macOS 12.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 80.47 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.13.2 - ~/.nvm/versions/node/v16.13.2/bin/node
    npm: 8.3.2 - ~/.nvm/versions/node/v16.13.2/bin/npm
  Browsers:
    Chrome: 99.0.4844.51
    Firefox: 96.0.2
    Safari: 15.2

Severity

serious, but I can work around it

Additional Information

No response

[dummdidumm]

This sounds like a usage question and not like a bug in SvelteKit itself, so I converted this into a discussion. If this turns out to not be the case, we can always reconsider.

Regarding your question: In your repo I don't see a monorepo setup. For me a monorepo is not just a repository with several independent projects, but something that defines how to glue them together, for example through yarn or pnpm workspaces. The problem is that just referencing the package won't suffice, you need to tell the mode resolving mechanism where to find it. The way to do this would be to make the package appear in the node_modules folder of the consumer, or a node_modules folder above that. For that, the package to consume needs to appear in its package.json. yarn/pnpm workspaces would achieve that, but you could also do that without it (not very pretty/robust) using just npm and adding something like "package-exported": "../package-exported" to the dependencies.

[RickMeijer]

Thank you for the quick reply @dummdidumm!

In short I expect the output dir of npm run package not to matter when consuming said package. But it does, which is strange to me. That is the heart of the issue. Or, in code:

...
    "package-external": "file:../package_exported", // Doesn't work (as in: the typing doesn't, components render just fine)
    "package-internal": "file:../package_internal/package", // Works
...

I agree workspaces would be a cleaner solution. Or anything but the solution presented here :D
We're still figuring out the setup that works best for us. Right now a file pointer one level up serves us well enough, considering scope, team size and time constraints. But I don't see the repo setup as part of the problem that needs to be solved right now. It all boils down to a symlink inside the node_modules folder pointing to a folder.
Why one is working and why one isn't is the real mystery here (to me). Hope this clarifies things a bit.