If I want to implement this, i guess i should add checks here:

reading the config there and extend the logic? I'd be able to create a PR if you agree to implement this.

Please elaborate more on the "plugins" and your intended usecase. The naming scheme is kept simple on purpose to allow users to easily recognize server-only paths by looking at the file system path (or list them with find etc).

Maybe it's also worth exploring alternatives like an additional vite plugin that enforces your extra rules instead of making it part of sveltekit core.

For the time being i would recommend you don't continue working on your PR until this has been discussed and agreed upon.

another workaround that could work with the current sveltekit feature is to use .server. not in the filename but in a directoryname, eg /lib/plugins/myplugin/for.server.only/module.js

edit: see below, doesn't work.

At the moment you are not able to protect any code from node_modules beside the .server.ts / .server.js.
Also this is true, when you want to structure your code not going split into different directories.
Like

• src
• • plugins
• • • LDAPDirectory
• • • • server
• • • • • hooks.middleware.ts
• • • • components
• • • • • OwnCustomComponent.svelte

another workaround that could work with the current sveltekit feature is to use .server. not in the filename but in a directoryname, eg /lib/plugins/myplugin/for.server.only/module.js

this doesnt work, since it checks only basename

return ILLEGAL_MODULE_NAME_PATTERN.test(path.basename(id))

Looks like you two are the same person or working together?

Protecting exports from packages in node_modules is out of scope of sveltekit i think.
These packages can use exports maps to limit where their exports are exposed.
eg:

"exports":{
  "./server/foo.js":{
    "browser": "./dist/not-allowed.js",
    "default": "./dist/foo.js"
  }
}

sveltekit is an application framework, so i'm confused why you are using src/plugins , and similarly why you can't use src/lib/server/plugins for code that should only be used in the server.

in fact im same person, thats why I deleted and repost.
Check structure above, a Plugin could also provide Components and so on. So I'd need to split code in different directories.

the packages exports won't help. svelte does not care about it, does it?

Still completely in the dark what kind of plugin you are building. Is this a vite plugin? a sveltekit plugin? a plugin for a custom application architecture on top of sveltekit? just sharing a few possible paths does not give a good picture.

this feature would increase the complexity of sveltekit and comes with ongoing maintenance cost so we have to understand it first and agree that it beneficial for sveltekit to have or if there are ways to achieve the goal in userland.

Its a business application (SaaS) written in sveltekit. It comes with a PluginManager.
The PluginManager loads Plugins dynamically and offers hooks to the Plugins to integrate different functions. The Functions are not only server side but can also implement Components and Config pages. Plugins can be turned on/off during runtime. One Example are UserDirectory Plugins. The Application supports different Identity Providers, like Active Directory, EntraID, Atlassian Crowd and others. Each IdP will be connected by a different plugin.

Isn't this already supported following this structure?

lib
└───plugins
│   └───myPlugin
│       │   file1.js
│       │   file2.js
│       │   file3.server.js

Isn't this already supported following this structure?

lib
└───plugins
│   └───myPlugin
│       │   file1.js
│       │   file2.js
│       │   file3.server.js

sure, you have to make sure every name has the .server. naming convention, but this wont help for npm modules which arent svelte exclusive.

What you described above are plugins for a custom sveltekit application architecture. the import guards by sveltekit won't help outside of sveltekit either so npm modules that want to ensure their code is not used on the client/or want to provide different code for the client are going to have to use exports conditions to do that.

Yes you are right. I was already thinking off plugins/module gonna distribute a
.svelte.kit.serveronlypaths file or something different and scan for it on build - but to make this work, sveltekit needs a way to extend the list what is done with my suggestion.

also devs implementing 3rd party modules would need the freedom to manually extend the list, because the implemented module isnt even aware of svelte - like typeorm

Any chance to get this in some way implemented? I dont see a way to do this with a plugin since SvelteKit doesnt an interface to this part.