Should the default build be static/local?

[0Ky]

I'm wondering if the Vercel adapter should really be enabled by default in the theme.

With this in astro.config.ts:

import vercel from '@astrojs/vercel'
adapter: vercel({ imageService: true }),
output: 'server',

bun run build works fine locally, but bun run preview fails because the Vercel adapter doesn't support Astro's preview command:

$ astro preview
[preview] The @astrojs/vercel adapter does not support the preview command.
  Location:
    /web/node_modules/astro/dist/core/preview/index.js:49:15
  Stack trace:
    at preview (/web/node_modules/astro/dist/core/preview/index.js:49:15)
    at async runCommand (/web/node_modules/astro/dist/cli/index.js:197:28)
    at processTicksAndRejections (native:7:39)
error: script "preview" exited with code 1

At the moment, the only way I can do a normal static build and preview locally is to comment out the adapter and output: 'server'.

Wouldn't it make more sense for the theme to default to a static build for local development, with the Vercel adapter being something you enable when you actually want to deploy to Vercel?

Maybe a deployment-target approach would make more sense here?

For example, having separate build:vercel, build:netlify, and build:cloudflare build scripts in package.json, while keeping the regular build as the default local/static build.

That way, you explicitly choose the deployment service when you want to build for one, without having to edit the config/code each time.

[cworld1]

the deployment tutorial of the official Astro document is quite simple enough. separates like build:vercel seems to simplify, but it is hard for users who want to change the options. for example, @astrojs/ vercel#Configuration has abundant custom options and some even should follow the personal settings on vercel.

and seems it is hard to wrap configs without having them to be the dependencies of the project. users must don't want to use the templates with unused adapter dependencies, just because without them, the project will print some errors even if them don't use them.

Actually I have thought the project demo could be constructed on the GitHub Pages, but soon I got rid of this.

1. The GitHub Pages, sadly, had been rejected in some regions of the world.
2. vercel could show the special features of Astro, like on-demand rendering and island rendering.
3. some services of the vercel could provide better experience for project developments, like pr status hints, branch-made deployments, accessibility checks and online inspections.

but if you have some better methods to keep the production and take into account the differences in local development, it is welcome to tell me.

[0Ky]

I think we may be mixing a few different concerns here. What I'm addressing is something entirely different. It's that I don't think a specific deployment target should be imposed as the default configuration of an otherwise generic Astro theme and I'm not saying that Vercel support should be removed.

separates like build:vercel seems to simplify, but it is hard for users who want to change the options.

It doesn't make it hard for users who want to change the options, the adapter config would still live in astro.config.ts either way, so nothing about picking which script runs astro build limits customization at all. Have a look at this package.json and astro.config.mjs, so you can have it keyed off an env var.

and seems it is hard to wrap configs without having them to be the dependencies of the project

If the goal is to avoid unused dependencies entirely for best practices, then don't import every adapter into one config file. You can use separate config files or have a build script to install the adapter when the user chooses a specific deployment target.

users must don't want to use the templates with unused adapter dependencies, just because without them, the project will print some errors even if them don't use them.

There's nothing wrong with having multiple adapter packages as dependencies, it's completely normal for a theme template. You can let the user decide to pick the adapter instead of defaulting to one. Astro's own adapter packages are designed to coexist without it causing any problems. Also, I'm not saying deploy to all, users will still have to pick one of their choice of an adapter, but I'm requesting it to make it easier for them which also addresses a build issue out-of-the-box.

1. The GitHub Pages, sadly, had been rejected in some regions of the world.

I don't think that's true, at least not anymore, unless you're strictly talking about the great firewall of China, then it probably would have applied to github.com domain as well, and in that case none of this would actually matter. It appears to be partially blocked only in China, which most likely applies to GitHub itself too. This shouldn't restrict you from still using GitHub pages for the live demo, you could always use multiple deployments only for the live demo page.

* GitHub Pages is not blocked in any other country

2. vercel could show the special features of Astro, like on-demand rendering and island rendering.

Those are not exclusive to Vercel. Vercel doesn't make Astro capable of using Islands Architecture. Astro can use Islands Architecture regardless of where the site is deployed, including other static hosting and deployment services. Islands Architecture is just an architectural choice about how you structure your web application, keeping most of the page as static HTML and using JavaScript only where interactivity is needed, and on-demand rendering is also not a Vercel exclusive feature. It's basically server-side rendering (SSR), which is useful for pages where the HTML depends on the request, where you have external server-side data, authentication or dynamic routes that require runtime rendering, none of which really applies to this theme.

3. some services of the vercel could provide better experience for project developments, like pr status hints, branch-made deployments, accessibility checks and online inspections.

PR previews, branch deploys and accessibility checks aren't Vercel exclusive either, Netlify's Deploy Previews post Lighthouse accessibility scores directly on the PR and Cloudflare Pages does per-branch preview deployments too, so none of that is Vercel exclusive.

Ideally, you should keep the template adapter-agnostic and output: 'static' by default, so that the following:

git clone -> bun install -> bun run build -> bun run preview

would just work with zero source edits, the way the README currently implies it should, but it doesn't. I would make a conditional adapter selection that a deploy target can be optionally selected by the user (env var, separate script or even a small CLI prompt on setup) rather than something baked in. The demo site can absolutely still run on Vercel, that should be a separate decision from what ships with the theme for everyone who clones the repo.

Maybe using something like an interactive CLI setup wizard using @clack/prompts, where the user runs it once after cloning and it sets up their environment, like which adapter package to install and add to astro.config.ts (advanced flag could delve deeper into each options for that chosen adapter or just be opinionated and set the bare minimum), insert site name and other configurations required to personalise the site in site.config.ts, so now there won't be any unused adapter dependency.

[cworld1]

using env to choose looks great. but i don't think we need to add all other adapters still. the official documents is easy to understand. we can add specific env to the vercel so that the deployment only triggers vercel adapter on vercel.

this project isn't a predefined and user-friendly template for making all steps out-of-box like Omarchy with all popular ai tools. Astro actually is known for higher customization, while other generators like Halo, Hexo or huge takes more sight on making processes more user-friendly.

Sadly still, Simplified Chinese users have accounted for a very large part. issues, pr, discussions, and showcase. we cannot ignore them. and most of Simplified Chinese speakers are Chinese, affected by the chinese firewall.

SSR is not Vercel exclusive feature, but it is now enough good. Or we can say, if we choose the Nelify or the Cloudflare pages, they actually can provide, but does not make sense for current developing, right? and till now, i think multi demos is not needed, and it does not improve the experience when visitors firstly get to know the project.

CLI setup wizard looks awesome, but i'm not sure if we changed the config format, will it works as before. if it is not, perhaps we should follow the kiss principle (keep it simple, stupid).