The point of src/islands is for the framework to know to make the component available as an island, it's to support non-.astro pages (see the src/pages/index.tsx example above. The folder name is not important, but Astro would need to have a special folder to do the island-wrapping part.

Note, there are probably other solutions to this problem that don't require a special folder, renderers providing an Island component ala import { Island } from '@astrojs/react'; <Island><Counter></Island> or something is another idea. I think it could come in many shapes, maybe even different shapes in different frameworks if that makes sense to do. But an islands/ folder is one idea we've discussed in the past.

ah gotcha, didn't realize that non-.astro components were in scope for this (didn't clock the .tsx file extension). Will need to think about that more

I think a minimal core should still be enough to build a typical Astro website. Also following the rule of three.

Yeah I'm also not sure content should be part of core, it could work perfectly fine as an integration in this new model. But if it's part of core, maybe it should be built as an integration internally

Note, it could be easier to discuss these things individually if they were separate comments/threads. Will reply here though:

• I'm hoping that server islands can be, implementation wise, the same as client islands, so I don't think I see a difference as far as where they live. The src/islands/ folder is a signal to Astro to wrap these thing so that they can be served differently. Exact details of how it works is yet to be determined.
• I don't think it means being able to nest frameworks like that. Again, depends on how the implementation works, but an island is just a wrapper <astro-island> and that could (probably) be done with a new hook in the renderer API to do the wrapping. For example renderer.createIsland(Component) gives you back <Island componentPath="/path/to/code.js" ...><Component /></Island>. Something like that, so it doesn't have anything to do with component interop.
• Yeah I was thinking that src/app.ts is optional, without it you get normal file-based routing behavior, just none of the extra request features (like i18n, middleware).
• I was thinking that in v7 if you don't provide an app.ts you essentially get one created for you that's equivalent of what v6 does for you. So that's the migration strategy I see.

Also worth noting, this is less about "move everything to @astrojs/ integrations", which might not be possible or practical in some cases, and more about realigning Astro around routing, islands, and content, and considering everything else to be (potentially) replaceable. I don't want to require you to install @astrojs/astro to get .astro templates for example.

We did this one time with src/pages/ be configurable but it turned out to cause a mess internally so we removed it. The user can configure srcDir, but then pages/ is reserved, so I imagine islands/ would be too. Name can be bikeshedded or course.

We're assuming this proposal wants to break down non-core features to integrations, and I strongly believe it shouldn't be the case, or to be more precise, I don't think the integration mechanisms is powerful enough to unlock all these features.

Another reason why "minimal core" can't be the package astro is the CLI.

I would envision a @astrojs/core being part of this proposal, and astro decorate it will additional features:

• CLI
• extenders (middleware, actions, etc.)
• etc.

The proposal leaves that outside of it, which makes sense. My message is to call out to avoid threads that could go too much into the technical details

Yeah I'm assuming we're talking about extracting features as integrations (I agree currently they do not enable it tho) because of this goal:

Move non-core framework functionality out of Astro core

I didn't intend to say that absolutely everything in astro will be extracted to an integration; some thing might be difficult or non-practical to extract. Of course I don't want to force a user to install an extension to get .astro file support, for example.

A goal here that I should make more explicit is to actually avoid having an astro- version of everything, even through integrations. That's a big part of the reason for app.ts, you can do a lot of the things we previously added features for (like rewrites) in that file, on your own, or use regular non-Astro 3rd party libraries.

So I'd say a secondary goal here is to make Astro easier to use with the wider JS ecosystem.

I was thinking of our file-based routing structure and logic as part of that. Maybe not even the router itself (I could see a reason to swap in Hono or something else to use as the actual router).

This is a big reason for having app.ts. You don't really need middleware, rewrites, redirects with that, because you are in front of the request and can do that sort of thing directly there.

I was thinking of our file-based routing structure and logic as part of that. Maybe not even the router itself

So maybe the RouteData[] and the sorting algorithm?

Yeah basically, the file-system walker that produces all of that.

If moving some parts to integrations,

As highlighted here #1318 (reply in thread), the proposal is generic so that it doesn't say "integrations everywhere".

I suggest trying to be generic with questions, and leave the implementation details if and when the RFC moves to stage 1

@HiDeoo I'm not sure that i18n would be an integration like that, but assuming it was, I would expect that Starlight is like a mega-integration (which it already is), and it would take in i18n config and pass it to the i18n integration that it adds itself, rather than the user adding it separately.

I see, I'll keep that conversation (if needed) for stage 1, but just to comment on:

I would expect that Starlight is like a mega-integration (which it already is), and it would take in i18n config and pass it to the i18n integration that it adds itself, rather than the user adding it separately.

It's already the case, altho we also support users providing a complete Astro i18n config for advanced use cases, e.g. embedding Starlight in an existing Astro i18n setup.