Allow feature based folders instead of separating by tech (island/routes/etc)

Going to open a discussion here before creating an issue with a description of what needs to be done. I see a few approaches to this which could be fine:

1. Introduce a new directory in which we do app-directory-next-style routing
2. Use the same directory, and have islands be named something.island.tsx and components be named something.component.tsx (or another pattern)

What would your preference be?

twind v1 remaining issues - #1116

Would like to bring attention to an elephant in the room 🐘.

Twind is like tailwind a great tool - however using it without the right tooling makes it painful and difficult to learn. The vscode-twind-intellisense is only maintained by 2 contributors, last commit was 2 years ago and it has been broken since typescript 5 was the default in vscode.

@Norfeldt That's a very good point and something that concerns me as well. On top of that I feel like moving to a non-runtime solution would fit better into the Fresh philosophy too.

@Norfeldt That's a very good point and something that concerns me as well. On top of that I feel like moving to a non-runtime solution would fit better into the Fresh philosophy too.

And tailwind can't be used? Or is there a problem with it?

Sorry, to clarify, are you talking about Tailwind the specification, or Tailwind the PostCSS plugin, or perhaps something else? With unocss (which is what I believe we're thinking about adding / moving to), we should have all of the Tailwind classes as with our current solution.

@Norfeldt I'm all for using tailwind directly.

@Norfeldt I'm all for using tailwind directly.

On a related note, does Fresh support using stylesheets directly at the moment?

Yes. You can put them in your static folder and simply reference them using standard html link tags

FYI I've moved the app.use() idea to simplify the Fresh server setup to the next cycle. There is ongoing discussion in #1602 what the API shape should look like. I don't want to rush that just to get something in the current release and thereby create API churn once the proper API lands. It needs more time to cook, so moving that to next cycle.

This cycle is completed. Closing this issue in favour of the new one for the next cycle: #1618