codespaces-project-template-js and the browser-only React portfolio template

A template that asks for a browser and nothing else

The pitch is stated bluntly in the project documentation. Tools needed: none, because there is no need to install anything, all you need is a web browser. Prerequisites: none, because the template includes the development environment and a deployable web app.

The intended reader is anyone who wants a portfolio site, wants to learn web development, or simply wants to try out Codespaces, and the documentation states that the experience level required is zero. That is a claim about the starting point, not about the ceiling: the same document says you decide how much you want to customize based on your experience and the time available.

The mechanism is a GitHub template repository, not a package. You click the Use this Template button, create a new repository under an owner of your choosing, then open a Codespace from the main branch. The repository ships sample data throughout, so the site runs the moment the environment comes up and you can deploy at any point before touching a single file.

Everything about the environment lives in the repository, which is the part that makes the promise work. A learner on a locked-down laptop, on a machine without Node, or on a platform where installing a toolchain is a chore, gets the same starting point as everyone else.

.devcontainer carries the operating system and the editor settings

The repository listing shows a .devcontainer directory at the top level, and the documentation names its two files. .devcontainer/Dockerfile is the configuration file Codespaces uses to determine the operating system and other details, and .devcontainer/devcontainer.json is the configuration file that tells Codespaces how to configure Visual Studio Code, such as enabling additional extensions.

That division matters more than it first appears. The Dockerfile decides what the machine looks like, which means the Node runtime, the package manager behaviour and the shell are decided by files you can read and change, rather than by whatever the host happens to have. The devcontainer.json decides what the editor does inside that machine, so an instructor can add extensions for the whole classroom at once by editing one file in the template.

The rest of the tree follows the same logic. The /src directory holds the HTML, JavaScript and CSS files used to build the portfolio site. The .eslintrc file holds ESLint settings for code consistency, and the .prettierrc file holds Prettier settings used to format the code. package.json and package-lock.json define the project information for Node.js, the dependent packages and the versions needed of each.

The end result is that a Codespace is reproducible from the repository alone. The same is true of a local checkout, which is the point to keep in mind when you decide whether you need Codespaces at all.

Parcel does the building, gh-pages does the publishing

The build tooling is Parcel, and the script list in package.json is where you can see the whole publishing path:

  "scripts": {
    "start": "parcel",
    "build": "parcel build",
    "build-gh": "parcel build --public-url 'https://{github-username}.github.io/{repo-name}'",
    "predeploy": "npm run build-gh",
    "deploy": "gh-pages -d dist"
  },

The start script runs Parcel in development mode, build produces a production bundle, and build-gh produces that bundle with a public URL pointing at a GitHub Pages address. The two placeholders in that URL, {github-username} and {repo-name}, have to be replaced with your own values, and nothing in the documented steps automates that substitution.

The deploy chain is deliberate. predeploy runs build-gh before every deploy, so the published output always carries the correct base URL, and deploy publishes the dist directory through the gh-pages package, which is listed in the dev dependencies.

The application dependencies are minimal:

  "dependencies": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  },

React 18 plus the Parcel build, the linter, the formatter and the publish tool is the whole stack. There is no test script in this block, and the repository listing shows no test directory and no continuous integration configuration, so the template gives you a development environment but not a safety net.

Customizing means editing one object called siteProps

The site is organised so that each section of the portfolio is a separate React component, and the personal details live in a single place. The documentation is explicit that your information needs to be set in only one spot, and gives the reason: it is as much about being able to see how prop values are passed to React components as about ease of updating.

That object is siteProps inside /src/App.jsx, and it holds the key value pairs for your name, title, email and social accounts:

const siteProps = {
  name: "Alexandrie Grenier",
  title: "Web Designer & Content Creator",
  email: "[email protected]",
  gitHub: "microsoft",
  instagram: "microsoft",
  linkedIn: "satyanadella",
  medium: "",
  twitter: "microsoft",

The example values are placeholders pointing at existing accounts, and the object continues beyond the excerpt the documentation shows. Because the links are data rather than markup, a learner can repoint the social entries without touching component code, and can then open the components to see where each prop is consumed.

That is the pedagogical payload of the template. The three customisation steps the documentation describes begin with the about and social data here, and the project pairs them with Copilot as an optional assistant: before creating the Codespace it tells you to enable GitHub Copilot for your account, and the sections after that are titled as a three step customisation flow. Copilot is a convenience layer, not a dependency. The site does not need it, and the template works without it.

The manifest still points at Microsoft and at ISC

The package.json in this repository describes a different project. The name field is educator-js-codespace-template, the description is Educator JS Codespace Template, the author is Microsoft, the licence field says ISC, and the repository, bugs and homepage fields all point at microsoft/codespaces-teaching-template-js rather than at the location this template now lives in.

The dependency versions tell a similar story. Parcel is declared at ^2.7.0, ESLint at ^8.23.0, Prettier at ^2.7.1, gh-pages at ^5.0.0 and React at ^18.2.0. Those are caretted ranges, so the floors are specific releases, and a template that a student will keep for a year inherits them as the starting point, so a learner who wants a current React or Parcel has to update the manifest themselves.

The licence question is the part to settle before you publish anything derived from this. The repository is identified as MIT and ships a LICENSE file, while the manifest field says ISC. Both are permissive, but they are different texts with different notice requirements, and the package.json is the field that tooling and registries read. Read the LICENSE file in the repository and copy its notice into anything you publish.

For an instructor, the drift is not a blocker. It is a demonstration that manifests rot when a template moves between organisations, and it gives a class something concrete to look at.

Codespaces or a local Node install, and the limits of the template

The genuine alternative to this workflow is to skip Codespaces entirely, clone the repository on a machine that already has Node, run the same npm install and npm start commands locally, and open the Parcel dev server in a browser. The build output is the same, because the toolchain is declared in package.json either way. The difference is where the environment comes from: the Codespace reproduces an operating system and a set of editor extensions from .devcontainer files that the template author controls, while a local install depends on what the developer already has and how they configure their editor.

The template earns its place in classrooms and workshops for exactly that reason, and it is less useful as a foundation for real work. There is no test script, no lint rule beyond the default configuration in .eslintrc, no CI workflow in the repository listing, and no backend. The site is a static frontend with a GitHub Pages deployment path and a set of placeholders to replace. A team building an application will outgrow the structure quickly.

One more limit is worth naming. The documentation describes creating the Codespace from the main branch and deploying from there, and the deploy URL contains two placeholders that must be filled in by hand. For a first portfolio that is a fine trade, and for a shared template that many people copy, it is a rough edge someone has to clean up on every fork.

Editorial conclusion

This template is a good fit for teaching, workshops and a first portfolio site, because the whole toolchain is described in one README and the working environment arrives with the repository. It is a poor fit as a starting point for a production React application, since the build is Parcel with no test script and no CI configuration in the repository listing. Before you build on it, read the scripts block in package.json, where the deploy target is a gh-pages publish to a GitHub Pages URL pattern, and check the licence and author fields, which still name Microsoft and ISC while the repository is identified as MIT.

Frequently asked questions

Official sources

1. github-education-resources/codespaces-project-template-js on GitHub
2. Issues
3. License: MIT
4. README