Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After issues with Deno & Lume, @Yatekii was looking to migrate to something new. As a fresh-eyed former corpo-backend-drone, I was looking for something real to get hands on with frontend & the way the rest of the world operates.
Preview on the PR repo's GH Pages: https://julianguide.github.io/probe.rs-astro/.
Framework Choice
I played with a bunch of different options for previous (smaller) projects (HTML & CSS, Jekyll, homebrew SSR with Markdown, homebrew SSR with MDX, Next.JS), but they all fell short somewhere, until I stumbled across Astro. Things just worked, and when I hit snags, it wasn't too hard to work around them (and often in the process, I discovered there was a standard way to do it that I had missed). I'm not naive enough to believe it will be around forever, but it's flexible enough and close enough to common standards (JSX) that I think it would be easy to migrate again.
Rewrite vs Migration
That said, this is more of a rewrite than a migration. There's a lot of good stuff in the current site (components, styles, layouts) that could be copied over. If you prefer to keep more of the old feel, I won't be offended :) It's pretty easy to embed whatever components you want, so all your old React components could come play in Astro land, and we could add in
.scss
support to import the old styles.Targets Data
The former site fetched targets and manufacturers data with
fetch()
. I've now introduced the targets as an NPM dependency, which keeps it locked to a specific git ref, which can be updated by workflow. However, this requires the dep repos to either A) include a basicpackage.json
in the root, to be recognized by NPM, or B) get fetched via 3rd party, https://gitpkg.vercel.app/. We could also movetargets/
into their own repo. Any preference?