Remote functions locations

[jycouet]

Describe the problem

I was excited to push this to prod quickly, now that it's in 🎉 (even experimental)
So, bumping a few deps, adding the flag, I'm ready to add my first at.remote.ts... But no! I get a 404 when I call it... I try to build because sometimes diagnostics give a good hint and I got:

[vite-plugin-sveltekit-remote] Expected to find metadata for remote file /home/jycouet/udev/gh/jycouet/jyc.dev/src/modules/at/agent.remote.ts

Hmm, not sure what I did wrong... Let's take a few steps back and re-read the docs — maybe something has changed :)

I don’t find anything obvious.

Ok, let’s do a repro... Of course everything is working...!
So it’s definitely in my code! But where...

And with the source code, finally I found it! Tadaaa:

kit/packages/kit/src/core/sync/create_manifest_data/index.js

Lines 483 to 484 in 5142acc

	// TODO could files live in other directories, including node_modules?
	for (const dir of [config.kit.files.lib, config.kit.files.routes]) {

So, 👉 You have to put your remote functions in /src/routes or /src/lib for now

Describe the proposed solution

First things first, it was a bit hard to find what I did wrong. Maybe:

• It could be stated in the docs for now?
• The error message during build could also give a hint about this?

---

In my case, I have two setups that might be interesting to take into account:

1/ I have a $modules alias pointing to ./src/modules.
=> Adding all of src would maybe be a good first step?

2/ I have an alias pointing to another project in my monorepo, like:
$superInternalLib pointing to ../../superInternalLib/src/lib
=> Adding all of the monorepo (excluding node_modules) would maybe be a good second step?

---

Adding node_modules seems a bit "risky" if not done carefully…
Maybe there’s an extra safety layer to add - like explicitly allowing remote functions from specific node_modules (e.g., "I trust node_module A")?

Alternatives considered

No response

Importance

would make my life easier

Additional Information

Let me know what you have in mind. I'll be happy to do a PR! :)

[dummdidumm]

This is a sort of a more general problem. We have config options for the lib and routed path but not the general src directory (and you could configure it such that lib and routes don't have a common base).
Right now we traverse the routes and lib path. Options I see:

• traverse common root (with some bail out heuristics)
• add src option
• adjust the retrieval of the remote functions somehow to be picked up while compiling the files, which might turn out to be impossible because we're currently adding remote info to the manifest which happens before vite compilation

[jycouet]

What about allowing alias paths ? (maybe it's not that straight forward, I don't know)

[aster-void]

Just stumbled upon this before, and took me a long time to solve.
Could you please add this to the docs? until maybe it's "fixed"?

[jycouet]

Yes, PR is up for the quick info 👍

[madeleineostoja]

I'd love to see the lowest lift here implemented rather than bikeshedded since it's under an experimental flag anyway, which I imagine is adding a src option? Personally I don't use the $lib alias at all, and having my RPCs under routes feels weird because there aren't any actual routes there, and for this application colocating remote functions with particular routes doesn't make sense.

Also even with docs this feels like a big footgun, since .server.ts files can be located anywhere