[examples][frameworks] Add support for Astro #6477
Conversation
stramel
changed the title
|
If it helps to get this looked at, Github published some stats on popularity & growth as a part of merging our syntax into Github.com code syntax highlighting: github-linguist/linguist#5460 (comment) |
| 'Astro is a next-generation static site generator that mixes lightning-fast performance with modern developer experience.', | ||
| description: 'An Astro site, using the default starter kit.', | ||
| website: 'https://astro.build', | ||
| envPrefix: 'SNOWPACK_PUBLIC_', |
There was a problem hiding this comment.
I believe this is still SNOWPACK_PUBLIC_ since internally it is using snowpack. I don't believe this has been aliased yet. @FredKSchott can you confirm?
There was a problem hiding this comment.
Sorry, I should have been more clear. This is used for Vercel.
https://vercel.com/docs/environment-variables#system-environment-variables
There was a problem hiding this comment.
Sorry, I think I'm missing the point of this property. The comment on the Framework typing says it is used to inline values into the browser bundle.
/**
* The environment variable prefix used to inline values into the browser bundle.
* @example "NEXT_PUBLIC_"
*/
envPrefix?: string;This would be how the developer could utilize the vercel env vars in their builds, correct? If I wanted to use VERCEL_ENV in my browser build I would need to use NEXT_PUBLIC_VERCEL_ENV for next? If so, I believe it would be SNOWPACK_PUBLIC_VERCEL_ENV?
There was a problem hiding this comment.
Yep, that sounds right. Are there Astro docs that show this usage?
There was a problem hiding this comment.
@styfle I don't believe there is anything in the docs currently. I know the team just launched the docs site recently. I will file an issue to add it to the docs. In the meantime, you can see that the docs site itself utilizes the SNOWPACK_PUBLIC_ prefix.
https://github.com/snowpackjs/astro/blob/main/docs/README.md
https://github.com/snowpackjs/astro/blob/23735c53cc59e489cf1d0f528a97c2ce535d0a21/docs/src/components/AvatarList.astro#L9
Related issue: withastro/astro#873
There was a problem hiding this comment.
Ok lets wait to see what happens with the upstream issue.
I'm also wondering if we should wait for JS files to be hashed so we can cache them per this comment
There was a problem hiding this comment.
Sounds good! I will also open a RFC around additional file hashing in the production builds to keep the conversation going.
styfle
changed the title
There was a problem hiding this comment.
I think we should wait until Astro 1.0 is released (or at least a RC) before supporting zero config, otherwise we'll have to have two presets to avoid breaking changes:
- Astro 0.x
- Astro 1.x
The reason is, we can't safely add caching for JS files so it will have to be versioned.
See this comment.
Furthermore, it sounds like the SNOWPACK env prefix might change to ASTRO.
See this comment.
Putting this on hold until both of those can be addressed by the Astro team.
|
Not opposed to that at all, makes sense if this multi-version support would be difficult to manage. Once we reach 1.0 I don't expect larger changes to the degree that your deployment defaults would need to change. |
|
Superseded by #7747. |
This adds the framework Astro to the list of frameworks. We're hoping to improve upon this template after getting the initial one added and we find ways to optimize it further.
Example was generated using
npm init astro/cc @FredKSchott @matthewp @natemoo-re @drwpow