OSD700 - the journey coming to an end

In the last release, there were close to 100 items that landed on 2.8. Still, a lot has been moved to 2.9. Some were moved because there was not enough time, some were moved because they need more discussion and planning, etc. After all, like our professor has said, this leads to Technical Debt, and we have to pay it down later on.

So this release, each of us is focusing on the area that we own. As being busy is different from being productive, we are reassessing our goals from the beginning of the course to see what we have done and what still needs to get done. 2.9 is the last feature release, we want to focus on stability, performance, and bug-fixing so that 3.0 goes smooth.

On my side, the area that I think I'm most responsible for is Supabase related issues, ESLint which I have maintained before but did not to catch up with the new approach to create a shareable config. Along with a couple of issues that I'm assigned to and involved with.

Image banner loader

#2925
#3190

I have a somewhat unstable internet connection, when visiting Telescope, the banner image sometimes takes 1-2 seconds to load, a grey background is shown instead. I think that is a nice area of improvement we could work on as the banner is the first thing we see, it makes the first impression of the website.

Luckily, our backend image service is already quite responsive and accessible. It allows us to specify the width of an image, which we can use that to display responsive images with srcset attribute. Upon looking into the issue, I notice there are a couple of things I can improve:

Image sources in the image srcset are random because we are not asking for a specify image, the backend picks a random image per request, which defeats the purpose of responsive images. When resizing, the banner changes.
The default banner image size is '2000px', which slows down initial page load.
The image banner background is grey, a gradient background would be more pleasant to users.

What I did was to create a new image route that lets users specify an index that can generally guarantee the same image is returned every time, except new images are added to the backend. Without it, it is not possible to specify an image because the frontend doesn't know the image names. Now, I have a srcset where each source points to the same image.

I did not follow the "Blur Up" technique as it was quite old and complicated and gonna give the reviewers a hard time understanding the code. What I did instead was to display a tiny '40px' by width image that has a minimal loading time first, then load the main 2000px image in the background and transition it in when it finishes loading.

The new banner also has a new gradient background. I thought to share a couple of cool gradient generator tools such as https://uigradients.com/#AzurLane, https://cssgradient.io/shades-of-blue/.

Postgres Timeout

#3031
#3248

Since the integration of Supabase, we often run into issues with e2e test timeout on CI. When it happens, we have to trigger CI workflows again, which often passes in the second attempt. The error we got is 'An invalid response was received from the upstream server'. It is a Kong error and a very general one.

Luckily, Dave was also looking into it and he thought the problem was that other containers weren't able to connect to the DB before the tests run. We got on a call and Dave did live debugging and fixed the issue.

In the Supabase Dockerfile, all Supabase containers depend on the Postgres DB to work. When the DB starts, it needs to run migrations and other initial SQL scripts. On development, when other containers fail to connect to the DB when it's not ready, they crash but will restart because the restart option is set to unless-stopped. In the CI workflow, the start-up time of Postgres varies because it's running on unstable GitHub sandboxes. When the connection to DB is not yet successful, the e2e test, which starts after every container starts, will fail.

Refactor ESLint

#3245
#3253

Thanks to Francesco and others who have been working on making a shareable ESLint config, that is published on NPM and is used in our sub-packages. I have to admit I have not been following the development of the new configuration, which I partly configured.

There was a bug filed about running pnpm lint wouldn't finish, it must be because ESLint is taking a very long time to lint files or there is a bug with the config. To find out what was happening, I ran ESLint with the --debug flag and turned out ESLint was linting all files on my computer because the file pattern is set to **/*. Along with some improvement to our ESLint configuration noticed, I decided to refactor it.

Change eslint file pattern from **/*, which might include files from other folders to ./**/* so that it only lints the current folder. ESLint needs a file pattern to work.
ESLint supports shareable config as a package, the airbnb-eslint-config is one of those we have been using. We are making the same thing with @seneca-cdot/telescope-eslint-config. To use a shareable config, we only need to add the name to the extends array option. The current configuration does this, and puts other options in the overrides option. That was not necessary.
Extend plugin:react-native/all to use best React-native practices, such as no inline styles, alphabetically order classes, etc.
Upon using the updated configuration, ESLint found a new problem with Supertest being installed as a dev dependency versus production.
Add ts,tsx, jsx to file import resolver option in the base config, so there is no need to configure it in sub-packages.
.gitignore could be used in place of .eslintignore, which excludes files we don't manage.
Remove typescript-parserand @typescript-eslint/eslint-plugin the base config as only src/web uses it
Remove @eslint-plugin-react-nativeas onlysrc/mobile` uses it.