Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Folder Structure & Best Practices #183

Open
jycouet opened this issue Oct 20, 2024 · 4 comments
Open

Folder Structure & Best Practices #183

jycouet opened this issue Oct 20, 2024 · 4 comments

Comments

@jycouet
Copy link

jycouet commented Oct 20, 2024

First off, thank you for sv, is was a nice surprise!

I'm about to start a community template, but before starting I would like to know if you have already some "rules" in mind? Or it will come with doing ?


1/ hooks.server.ts
What about enforcing sequence and importing handle from the corresponding template?
I feel that any application will need this sequence and it would probably ease the installation of other template.

Example with auth:

import { sequence } from '@sveltejs/kit/hooks';
import { handleAuth } from '$lib/server/auth.ts';

export const handle= sequence(handleAuth);

2/ Folders structure
./src/lib/server/auth.ts vs ./src/server/auth.ts vs ./src/modules/auth/server.ts
Of course, everyone is able to do what he want after, but I'm wondering if we could put people in the right track from the start?
If we start to have a lot of community integration, having the same style would also be beneficial.

I'm using this structure in my app and find it quite convenient

src
  lib                
    assets
      logo.svg
    ui
      Button.svelte
  modules          
    auth
      hook.server.ts
      server.ts
      ui
        index.ts
        Login.svelte
  routes
    +layout.svelte
    +page.svelte

Like this, I also use $lib and $modules


Let me know what do you think, I'll be happy to help building this view.

@manuel3108
Copy link
Member

Thanks for sharing your thought process, bear in mind community adders are currently not supported (see #184)

Regarding number 1:
We already have a helper function for adding a handle to a hooks file. This is currently in example used by the lucia integration. Once the community integrations will become available, this helper will be made available to all community integrations.
In general we only enforce using sequence if explicitly requested by the integration, or if the file already contains an existing handle.

As for the folder structure we will probably stick to the alias for $lib that the default template already sets up. Adding other alias should happen in userland imo. The goal here is to get you started quickly, and not to fulfill everyone's wishes. If a user prefers to another directory structure, he can always move the files later on.

If you have any further thoughts, please let us know!

@jycouet
Copy link
Author

jycouet commented Oct 20, 2024

Thank you for sharing.

I would always add sequence for simplicity to enhance things in userland (without worrying about where to import it from ^^), but that’s just a personal preference and very minor. It’s great that you’ve already considered the one or many 👍

I have a stronger opinion (which is open for debate, no problem) about keeping features in one place as much as possible. In the Lucia example, some code is already spread across ./src/hooks.server.ts, ./src/lib/server/auth.ts, and v./src/routes/demo/lucia/*`. If someone adds a media module, the code could become even more scattered, which might not be ideal?

At the same time, I understand that 10 developers will bring 11 different folder structures 😅. Like with routes and +page.svelte, I think Svelte being opinionated is a good thing. So, I believe giving some strong recommendations for module structure would be cool (and then you can still do what you want in userland).

I also agree that sv shouldn’t set other aliases; that’s definitely a userland concern. In the past, I’ve set aliases under $lib, but then tooling (like VSCode) would always auto-import from $lib instead of the specific sub-aliases. It also feels a bit underutilized if you only have $lib in your app. I’m not entirely sure what to do with this thought, but I think it’s an interesting concern to explore for better community integration between plugins? templates? modules?

Oh, one more thing! I’d love to have +layout.svelte by default. (I remember an issue about it, but couldn’t find it.)

One community plugin could, of course, be my vite-plugin-kit-routes, but it might be better to revive sveltejs/kit#11406! Now that Svelte 5 is out, maybe I should take a look at this, and kill the plugin (that is a must to all apps 😉!)

@manuel3108
Copy link
Member

I think you have mainly answered the question yourself with this:

I also agree that sv shouldn’t set other aliases; that’s definitely a userland concern.

If we don't consider the possible alias-locations I do think that everything is exactly in the right place. We should also consider @AdrianGonz97 comment in #185 (comment), indicating the server-only modules

But I'd also love to hear input from the other folks.

Regarding the +layout.svelte if you find that issue and that's still a valid concern, please let us know.

@jycouet
Copy link
Author

jycouet commented Oct 20, 2024

Regarding the +layout.svelte if you find that issue and that's still a valid concern, please let us know.

Just found it sveltejs/kit#11335


I don't know if you want to gather inputs from others here or not? Feel free to close the issue when needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants