Convert to Eleventy.

[davidlehn]

Status:

• Second try at converting to a static site generator.
  • First try was to Jekyll in 2017: https://github.com/json-ld/json-ld.org/pull/461.
  • Much of the discussion there applies here after many years.
• There are many many many SSG choices. This conversion is using Eleventy. If the community wants to use another system, it's likely these conversions are a good start with similar patterns.
• What's happening in the initial commits here:
  • Handles pass through of all useful (and more) files that were served before.
  • Converts the runtime php indexing code to build time js code.
  • Some tweaks for uniformity.
• The plain apache+php hosting we use now could probably host this output with a few operational changes.
• Templates and various upgrades and improvements are not yet done. Solving issues one step at a time.

Issues:

• Basically same ones as in the jekyll issue.
• How to handle minutes/. It's gigantic and inappropriate to mix into a static site directly.
  • It is being updated on the main site AND on gh pages at https://json-ld.github.io/minutes/, but the logs note that 1.8G is beyond the 1G max and deploy might fail and it can take 20min+ to deploy. Another solution would be better. Also the "pre-wg" link is easy to not notice.
• How to handle the playground and playground php proxies.
• How best to host and handle updates.
  • May need content type and cors fixes depending on hosting platform.

Notes:

• One approach for many issues is a subdomain using gh pages or something else for minutes, cloudflare for hosting, cloudflare workers for the proxy. I think Benjamin likes this idea.
• We also need to decide how to improve the playground. No one at all wants to work on it as is. Integrating a web app build step into the static site process is doable but perhaps not the best approach. I'm pondering the site code here being more content based and (ab)using a CDN or gh pages to host built playground app bundles and resources. Suggestions welcome on that.

Testing:

npm install
npm run serve
# open http://localhost:8080/ (or whatever URL it gives you)

[cloudflare-workers-and-pages[bot]]

Deploying json-ld-org with    Cloudflare Pages

Latest commit:	a8a8b0c
Status:	✅  Deploy successful!
Preview URL:	https://49c7bfc5.json-ld-org.pages.dev

View logs

[davidlehn]

Another issue with this conversion is how to handle all the .htaccess rules. If the target host is Apache then of course these will still work. But our likely new target is Cloudflare Pages, which does things differently.

$ git ls-files | grep .htaccess
.htaccess
contexts/.htaccess
images/.htaccess
spec/ED/.htaccess
spec/latest/.htaccess
test-suite/.htaccess
test-suite/tests/.htaccess
utils/.htaccess

• CF has _redirects and _headers files, which are simpler and limited. Some of the .htaccess rules can be handled with those files. (Untested, but looks promising)
• The content type detection is trickier and I believe would require another _functions worker for some special cases. Effectively writing some js to do what apache rules do.

And while pondering these things, I'm wondering where this is headed.

• A good dev env is now rather complex.
• 11ty has the nice auto update dev server. But it's unaware of these htaccess or cloudflare rules. Making it difficult to actually test the entire site. To use the playground proxy (see other PR), you need to have a 11th proxy to a cloudflare wrangler dev server.
• Cloudflare wrangler could also serve the static dev site with its redirects and headers and functions. But then the auto update feature doesn't work. There may be some extra proxying to make that work. But then that would require two dev servers to do dev work, which seems a bit awkward.
• Should we make apache or cloudflare a build option? I suspect it will just flip which files get copied to the output. But that's two things to maintain and keep in sync.

[BigBlueHat]

@davidlehn per your concerns above, I think we can keep using 11ty separate from the hosting platform. Having 11ty in place makes working on (and redesigning) the site much simpler--where it's hosted can be a separate matter because 11ty generates static sites.

Cloudflare hosting can easily get more complex/tangled (just like the build tool nightmare that is modern JavaScript vs. ye olde <script> tag). It really depends on what we want to manage, pay for, support, etc. Most/all of the Cloudflare stuff, though, can also be defined descriptively (or at least via JS in the same repo) to avoid "blind"/hidden configurations available only via the Cloudflare Dashboard.

All that to say, how this is hosted is orthogonal to using 11ty.

[BigBlueHat]

@davidlehn how close do you think this is to shippable? I know #840 is part of the consideration here too. Just curious how we can get this over the finish line.

Since the WG is getting rechartered, it'd be super to get this in a space we can continue to improve, redesign, etc.

Happy to help finish it off...just not sure where we're stuck.