Creating a Node.js Website with GitHub Copilot Workspace Using Best Development Practices in R

A Minimum Viable Product (MVP)

My first “brainstorm” request was deliberately simple to quickly achieve a minimum viable product (MVP): (Out of habit, I talk to it in English. You can always speak to it in French; it will understand, but it will reply in English.)

A static website on github pages, updated through github actions.
The website :
- uses a list of gpx files stored in the repository as input,
- shows the gpx traces on a interactive map
- allows the users to click traces on the map to download them
- each trace has a category "sec", "humide", "boueux", allowing for selection of traces shown on the map

It is ok if the gpx traces need a preparation during website pre-build.

Development Ideas and Code Generation

Copilot Workspace then proposed several development ideas, corresponding to possible strategies to combine in order to meet my needs. At this stage, it was possible to choose:

• Generate only the plan, to clarify the project’s major steps.
• Generate complete code directly from the plan, to move faster.

Figure 3: My instructions on the left. Brainstorm output on the right

I first chose to generate a plan before moving on to the complete code.

Figure 4: The plan, with actions to accomplish on the left. Code generated automatically on the right.

Next, several options were available to me:

• Request a plan review (“Brainstorm”) to add ideas or clarify certain points.
• Review the generated code (“Revise”) if optimizations were necessary.
• Modify the code myself, using my development skills.

Smooth and Guided Development

When I was satisfied with the result, I was able to create a private GitHub repository directly from Copilot Workspace, generate commits, and push the code to GitHub.

For project updates, I started new brainstorming sessions to:

• Add features or improvements.
• Fix errors detected during continuous integration.

Copilot Workspace suggested making changes in the form of Pull Requests, facilitating a structured and maintainable workflow.

Concrete Examples

Among the proposals from Copilot Workspace:

• A classic structure for a web page, with folders dedicated to JS scripts, well separated according to functionalities: data preparation on one side, map interactivity on the other.

• A CI/CD workflow, with steps for data preparation, site building, and deployment on GitHub Pages.

• Assistance in writing the script for manipulating GPX files, to prepare them for display on the map, as well as in creating filter components on the map.

• A simple solution for managing GPX file downloads, allowing users to easily retrieve tracks for their hiking application.

• Valuable help in correcting the CI/CD workflow, assisting me in managing errors encountered during data preparation and site building (see screenshot).

Figure 5: Multiple independant brainstorm sessions to fix different CI/CD errors faced during development.

1. Copilot Workspace as a Tool for Technical Leads

Copilot Workspace is not just a simple code generator for writing or debugging a file in progress, it is a valuable tool for technical project execution.
Not only does it offer suggestions on how to approach your needs, but it also allows you to generate all the folders and files in the same interface, in one place, and at the same time. This is a significant time-saver, especially when setting up a new project. Additionally, since it is fully integrated with your GitHub repository, you can push your changes directly online.
It complements Copilot in your preferred code editor seamlessly.

2. Linking with Feature Requests

I could have gone even further by writing my needs as GitHub issues, with well-structured user stories and success criteria. I tested this on two issues to see. These issues can be opened directly in the Workspace, automatically generating “brainstorms”. Linking these issues to commit messages also improves project traceability. For tracking project progress with other developers, this is a valuable asset.

Figure 6: Screenshot of a GitHub issue with the button to open it directly on GitHub Workspace

2. The Importance of CI/CD from the Start

From the beginning, I deliberately forced Copilot to set up a CI/CD workflow. Even though I didn’t need to dive deeply into the JavaScript code, I was able to have functional code simply by asking it to fix the errors encountered in the PRs: “Here is the CI error message, can you help me fix it?”.

The time saved was considerable, especially for a language I am less familiar with. This choice confirmed a truth I already know from my R projects: CI/CD-related errors are often the most time-consuming and complex to debug, as we don’t always think about the specifics of a clean or different OS from our workstation…

I am therefore not surprised that an AI struggles to propose a functional CI/CD workflow on the first try. However, it was of great help in fixing these errors and making the pipeline reliable.

3. Documentation and Tests: Leaving Nothing Out

By default, Copilot did not suggest unit tests or function documentation. Thanks to my development habits with R, I made sure to quickly integrate unit and end-to-end tests to ensure that the outputs of the JS functions were consistent with user needs.

Similarly, my need for documentation (inherited from {roxygen2}) led me to ask it to document the functions and generate a documentation site, like {pkgdown}, with JSDoc: https://statnmap.github.io/gpx-traces-website/docs/. This approach made the project more robust and maintainable.

Figure 7: Documentation webpage of the project from JSDoc

4. Copilot learns from your practices

Once unit tests, function documentation, and README completion were set up, Copilot continued to suggest them for each project evolution. This also works with GitHub Copilot when you use it in VSCode.

Moreover, for Copilot (in general), working in a single Notebook file like with {fusen}, where documentation, code, and tests are centralized, greatly simplifies the AI’s job for code generation assistance… Just saying!

Note that this also works with commit messages. In Workspace, when you are ready to commit, Copilot can suggest automatic message generation. Similarly, VSCode locally offers this feature. If you use “conventional commit”, you will need to modify the first message, but theoretically, the following ones will retain your habits.

5. Managing Node Libraries

When adding Node.js libraries to your project, Copilot does not fully manage them automatically. You may need to manually add them to the package.json file and especially install them with npm install.

The good news is that Copilot Workspace often suggests the appropriate command in the last “Commands” section of the project steps. You can execute it directly in the integrated terminal by clicking on the execution icon next to the command. This saves you from having to bring the project to your local machine just to install the libraries.

Figure 8: Section ‘Commands’ lists all commands to be manually executed, and this can be run directly in the Copilot Workspace Terminal