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's Pull Request about starting to migrate 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 pnpm 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 is, how do you automate the release of a package that lives inside a monorepo?
Zoltan, the author of pnpm responded to Dave's tweet and said that we can actually use pnpm 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 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
The fixes 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's PR and also worked on improving the Getting Started page by taking advantage of a cool Docusaurus feature called tabs.
Since Docusaurus is build with React, we can actually use JSX in Markdown (which is actually MDX... 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 the end result is great and I cannot wait for the Docusaurus documentation to ship!
Top comments (0)