Packages, Docs and Accessibility
Tags: monorepo, pnpm, docusaurus, a11y
Published: 2022-02-12 03:40:03


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 reviewing [Thanh](https://github.com/tcvan0707)'s [Pull Request](https://github.com/Seneca-CDOT/telescope/pull/2805) about starting to [migrate eslint to our microservices](https://github.com/Seneca-CDOT/telescope/issues/2736) (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](https://github.com/Seneca-CDOT/telescope/pull/2862) 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 pnpm [workspaces](https://pnpm.io/workspaces) feature. For example to add the `eslint-config` package to a microservice, we would add it as a dependency in its `package.json` like this:

```
"eslint-config": "workspace:*"
```

This will search for the `eslint-config` package inside each workspace defined in `pnpm-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 the `eslint-config` package to the npmjs registry. The [question](https://twitter.com/humphd/status/1491873257007599620) is, how do you automate the release of a package that lives inside a monorepo?

[Zoltan](https://github.com/zkochan), the author of `pnpm` [responded](https://twitter.com/ZoltanKochan/status/1491876468225458179) to Dave's tweet and said that we can actually use [**pnpm publish**](https://pnpm.io/cli/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  this [issue](https://github.com/Seneca-CDOT/telescope/issues/1608) 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](https://web.dev/link-name/)
- [Heading elements are not in a sequentially-descending order](https://web.dev/heading-order/)
- [Tap targets are not sized appropriately](https://web.dev/tap-targets/)

The [fixes](https://github.com/Seneca-CDOT/telescope/pull/2884) take the page to a perfect 100 accessibility score which is nice to see.

![Lighthouse Accessibility Score: 100](https://user-images.githubusercontent.com/53121061/153653014-5b2196c5-66a8-4da2-ab3c-c9c824f85234.jpg)


## Docusaurus!

Last semester I loved working with Docusaurus but I was left hungry for more. This week, [Cindy](https://github.com/cindyledev) migrated the telescope docs to Docusaurus and I had to get involved!

I reviewed Cindy's [PR](https://github.com/Seneca-CDOT/telescope/pull/2869) and also worked on [improving the Getting Started page](https://github.com/Seneca-CDOT/telescope/issues/2882) by taking advantage of a cool Docusaurus feature called [tabs](https://docusaurus.io/docs/next/markdown-features/tabs).

Since Docusaurus is build with React, we can actually use **JSX in Markdown** (which is actually [MDX](https://mdxjs.com/)... 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.

![Tabs in markdown](https://user-images.githubusercontent.com/53121061/153673367-5687303a-e752-4995-afb0-39331132aa4a.jpg)

I think the [end result](https://github.com/Seneca-CDOT/telescope/pull/2888) is great and I cannot wait for the Docusaurus documentation to ship!