Is an experiment to see how tricky and convoluted things might or might not get when you build the exact same App with two JS frameworks at the same time, in the same Repo and then compare their performance, quirks, pains and gains alongside each other on the same hardware, using the same complimentary assets.
It is a continued WIP, growing into the shape I'm looking to achieve every week.
This template should help get you started developing with Vite and TypeScript in Vue.JS 3 and React 19 in the same house. Various Testing and CSS technologies are made available and applied by default.
The project is Domain-Driven Design-based and applies best-practice TDD approaches using Model-Driven evaluation, and Behavioural-Driven Design followed by Unit, Functional, Component, Integration, and End-to-End testing running on both the Playwright and Cypress testing frameworks. I've also included both Vitest and Jest to play around with Unit and Integration testing functionality.
Playwright and Cypress will be put through their paces to see how broad and wide they can be pushed to function from Unit testing all the way through to E2E testing.
For details on how the Project Template is structured, a VitePress Documentation section will be added to the repository's DOCS folder once everything is working reliably in the intended starting configuration. You can, if you feel the need, refer to the details covering each section, and expand on those when shaping the template as per your unique project requirements.
VSCode + Volar (and disable Vetur).
Refer to the .vscode configuration file for the recommended extensions. Should other IDEs be preferred, please refer to their respective extension marketplaces for suitable equivalents.
TypeScript cannot handle type information for .vue imports by default, so we replace the tsc CLI with vue-tsc for type checking. In editors, we need Volar to make the TypeScript language service aware of .vue types.
Strict Types are applied by default, and various TypeScript IDE tools are used to assist with making the DX clear, controlled and feature-rich, while driven by high quality standards, and practices.
We have added all the key VS Code Extensions we use under the .vscode folder. Look out for the extensions.json file, they are listed there.
See the Vite Configuration Reference. See the TypeScript TSConfig Reference.
The project is served by a locally installed Jenkins Server tunnelled to GitHub via Cloudflare's tunnelling technology. This specific template project will thus be kept up to date and managed in a suitable CI/CD pipeline workflow suited to the various and dynamic platform and framework integrations.
For more detail please refer to the DOCS folder for now. The project's tree will give you a bird's eye view of the general layout and how the pieces are interacting. Most, hopefully all, custom JS files will be converted to TypeScript to allow for future maintainability as well as flexibility to test the code in situ, while development progresses.
The Jenkins pipeline is a multi-branch type and is getting structured to accommodate a TDD approach instead of doing Unit and Integration testing as an afterthought. An example Jenkinsfile will illustrate how the CI/CD process will ultimately function from "continuous commits" through to continuous deployments while the Jenkins server is based on my local machine getting triggered by the Repo's webhook designed for that specific purpose.
To set up a Jenkins Server on your local machine as preferred, follow the official Jenkins documentation while also referring to the local Jenkins documentation in this repository to get started.
Ensure you configure a Pipeline with matching characteristics, then simply apply the Jenkinsfile available in this repository.
NOTE: The commands here are varied and growing, the final versions will be added here once they have been tested and gotten to work as expected. For more detail on the current NPM Scripts available to run, refer to the "scripts": {...}, section in the package.json file.
npm installnpm run devnpm run lint # Using ESLint and OXLint
npm run lint:eslint # Using ESLint
npm run lint:oxlint # Using OXLintnpm run buildWe can apply Vitest and Jest in various ways while building the project and these initial scripts are available.
npm run test:unit # Using Vitest
npm run test:vue # Using Vitest, Cypress and Playwright
npm run test:react # Using Jest, Cypress and Playwright
npm run test:all # Using Vitest, test:vue, and test:react
Running Tests with Playwright & Cypress
Component, Functional and E2E tests can each be ran with their respective scripts.
npm run test:component:cypress # Using Cypress
npm run test:e2e:cypress # Using Cypress
npm run test:e2e:playwright # Using Playwright
npm run test:vue # Using Vitest, Cypress and Playwright
npm run test:react # Using Jest, Cypress and PlaywrightThe Vite-TS-Vue-React-Prj-Template-2025 repository is both a user and an Iterative Development Project repo type.
NOTE: Depending on whether you have a registered TLD or Apex domain with some service provider or not, is where most of the confusion comes in, IMO. So before jumping in you need to step back a bit and consider your own unique situation and then decide which approach would be best-suited for your particular use-case.*
Here are a few (non-exhaustive) scenarios to hopefully set you off in the right direction: I am being verbose in each case as these subtle differences make ALL the difference.
- You only have a Personal GitHub account and want to host a personal project on GitHub Pages.
- You have an Organizational GitHub account and want to host an organizational project on GitHub Pages.
- You have a Registered TLD, and a Personal GitHub account and want to host a personal project on GitHub Pages.
- You have a Registered TLD only and wish to use the domain as the target URL to host a personal project on GitHub Pages.
- You have a Registered TLD and a subdomain of the TLD and wish to use the subdomain as the target URL to host a personal project on GitHub Pages.
- You have similar, but subtly different scenarios than the ones described above.
In this particular case the scenario is as follows: I have a subdomain hosted on my very entry-level Hetzner Cloud VPS, and it's routed through Cloudflare's WAF, SSL/TLS, and DNS services among other DevOps & DevSecOps utilities. I will be hosting this project's Backend on the Hetzner VPS (a Headless WordPress instance) and want the Landing Page, a simple HTML + Tailwind template "Frontend" hosted on GitHub Pages. Yes, Cloudflare Pages would probably have been an easier solution, but we'll get to it in due course, for we'll be hosting the Vue and React portions of the project on Cloudflare Pages. I want to host the Landing Page portion of the project on GitHub Pages. Additionally I want it discoverable through all-inclusive URL approaches like:
https://www.frameworkblurr.adpc-llc.com,https://frameworkblurr.adpc-llc.com,www.frameworkblurr.adpc-llc.comand,frameworkblurr.adpc-llc.com.
I have my Organizational account with GitHub as well as two personal accounts. As mentioned, this project is based in my main personal account. Based on the question found on SO I found it to be the most relevant one, so I went and configured the required DNS settings and applied my SSL/TLS certificates as managed via my setup on Cloudflare, while using the guidance of a good answer to these questions as shown below.
To get this done with the least pain, forget GitHub's documentation as it's all over the place, non-linear as the author mentioned, and quite convolutedly disconnected, IMO. So referring to this post by Ryan Pendergast on Stackoverflow I managed to make sense of how to get it set up for this slightly more involved configuration.
In the guidance it mentions the following:
- Choosing
master branchwill treat/README.mdas your webindex.html. Choosingmaster branch /docsfolder will treat/docs/README.mdas your webindex.html.- Choose a theme.
The current workflow for creating a new GitHub Pages deployment was not experienced exactly as per the flow described in the SO answer mentioned. Refer to the screenshot further below.
NOTE: I initially added the www subdomain prefix in this example to demonstrate the "ensuing chaos" that can occur in my specific scenario, but again, this is one of the subtleties, in my case it was a battle between setting up the DNS records in Cloudflare with assumed settings as gleaned from Ryan's SO post, vs what GitHub Pages' current DNS Record inspection spits out when the www prefix is used.
A good place to start would be to ask "WHAT" is the www prefix there for in a domain?
OK, so a common explanation you will find mostly is the following:
The "www" stands for World Wide Web and is a subdomain commonly used to indicate that a website is accessible via the internet.
Let's have a deeper look at how a web address or also commonly known as a "link" is constructed as well as how a Universal Identifier technically called a Universal Resource Locator (URL) is applied by humans and how computers, network routers, switches and search engines understand them in order to route us to the correct web address.
Things are more convoluted and there are thousands of questions related to the following "variants" of "links" in reference to the Internet.
I recommend we start this path off from some form of neutral authoritative ground, without re-explaining it here in detail, I refer you to two references to get onto the right path to finding answers:
- Mozilla Developer Network's (MDN) World Wide Web documentation.
- Mozilla Developer Network's (MDN) Choosing between www and non-www URLs documentation.
The steps at date of publishing this (15th Dec 2024), the setup steps on GH Pages were as follows:
GitHub Pages is designed to host your personal, organization, or project pages from a GitHub repository.
Source
Deploy from a Branch
Branch
Your GitHub Pages site is currently being built from the master branch. Learn more about configuring the publishing source for your site.
master / (root) Save
Learn how to add a Jekyll theme to your site.
Custom domains allow you to serve your site from a domain other than andre-adpc.github.io. Learn more about configuring custom domains.
www.frameworkblurr.adpc-llc.com Save Remove
DNS check unsuccessful
Enforce HTTPS — Unavailable for your site because your domain is not properly configured to support HTTPS (www.frameworkblurr.adpc-llc.com) — Troubleshooting custom domains.
HTTPS provides a layer of encryption that prevents others from snooping on or tampering with traffic to your site. When HTTPS is enforced, your site will only be served over HTTPS. Learn more about securing your GitHub Pages site with HTTPS.
All the above might be a bit unnerving, especially for folks who are not sure at all on how to navigate the "mysterious waters" of DNS, A records, CNAME conventions, etc. all that confidently just yet. However, there's no need to be concerned at this point. We have to start the process somewhere, and in most cases the logical thought process is to do so from the source, in this case the GitHub Repository we wish to publish on a live website.
As you will notice all these "red flags" are not revealed as explicitly in Ryan's post on Stackoverflow, but they would be when the process was started from the GitHub Pages UI
Should you experience trouble with configuring SSL/TLS connections, you can refer to GitHub Pages' documentation Securing your GitHub Pages site with HTTPS you'll be guided to add a layer of encryption that prevents others from snooping on or tampering with traffic to your site.
There's a handy AI Chat interface which will run an analysis to the extent of its abilities and guide you through potential issues.
It was so in this particular configuration's case and here's an excerpt of the chat: