There has been a lot of activity within the Telescope project and it's going so fast that it is hard to follow everything. From my end, I am still working a lot on monorepo tooling with Turborepo, but I also decided to pick other interesting issues.

Monorepo local package

After reviewingThanh'sPull Request about starting tomigrate eslint to our microservices (with the goal to speed things up with Turborepo), I realized that we would end up with many.eslint.js files containing a lot of duplicate code.

It turns out that it is possible to have a local package in a monorepo and share it to our microservices without having to publish it. So,the idea I had was to create a local eslint-config package and reuse it in all of our microsevices, thus reducing any duplicate code.

This is possible thanks to the pnpmworkspaces feature. For example to add theeslint-config package to a microservice, we would add it as a dependency in itspackage.json like this:

"eslint-config": "workspace:*"

This will search for theeslint-config package inside each workspace defined inpnpm-workspaces.yaml instead of searching the npmjs registry.

A local package seemed like a great solution in my mind by after opening the PR, we quickly realized that we still rely on npm in some places, so we will not be able to follow this path.

The other solution suggested by Dave is to actually publish theeslint-config package to the npmjs registry. Thequestion is, how do you automate the release of a package that lives inside a monorepo?

Zoltan, the author ofpnpmresponded to Dave's tweet and said that we can actually usepnpm publish.

According to the docs:

When running this command recursively (pnpm -r publish), pnpm will publish all the packages that have versions not yet published to the registry.

I still have to test and see if it will work, I will have an update on next week's blog, but I am hopeful!

Accessibility Improvements

Something that I really enjoyed this week was diving deeper into accessibility standards for the web. I started by picking thisissue about improving the accessibility of Telescope.

Since the main Telescope page is a feed of many blogs, we cannot control if the authors use proper accessibility standards. So what I decided to tackle was Telescope's About page.

Using Google Lighthouse, I found three accessibility issues:

• Links do not have a discernible name
• Heading elements are not in a sequentially-descending order
• Tap targets are not sized appropriately

Thefixes take the page to a perfect 100 accessibility score which is nice to see.

Docusaurus!

Last semester I loved working with Docusaurus but I was left hungry for more. This week,Cindy migrated the telescope docs to Docusaurus and I had to get involved!

I reviewed Cindy'sPR and also worked onimproving the Getting Started page by taking advantage of a cool Docusaurus feature calledtabs.

Since Docusaurus is build with React, we can actually useJSX in Markdown (which is actuallyMDX... mind blown!) and that's how the Tabs feature is implemented.

The idea was to separate the Docker installation guide based on the operating system (Windows, macOS, Linux) to simplify the reading experience.

I think theend result is great and I cannot wait for the Docusaurus documentation to ship!