Overview
With the implementation of upcoming features demanding more complex code, as well as more advanced interactions between different parts of the project, the project's structure must be in a good state to support these additions. Postponing refactorings can lead to technical debt that's difficult to overcome later. Features implemented to follow the current structure leave more work to be done later when we change to a new structure.
As such, this issue highlights pending refactorings that were not yet completed, due to the faster iterations we undertook to release the project sooner. Right now, before we expand further, is the most appropriate time to work on these changes, as they touch practically every file on the repo. There are not as many features built on top of the current structure to make changing it too difficult, and all subsequent additions to the project will benefit from it.
Pull requests created to address these changes should not change public-facing features. (Note that this does not include the API as it's not part of our public API yet.)
This, thus, basically includes commits marked with the refactor, chore, build, test, and style conventional commit types (but no feat or fix commits must be present). These include:
- Structural changes to the frontend project;
- Any change to the
backend and shared projects that does not disrupt what's returned to the frontend;
- Build, test, linting and overall project structure changes to conform to the new structure
Tasks
Project
Infrastructure
Shared packages
Backend
Frontend
Overview
With the implementation of upcoming features demanding more complex code, as well as more advanced interactions between different parts of the project, the project's structure must be in a good state to support these additions. Postponing refactorings can lead to technical debt that's difficult to overcome later. Features implemented to follow the current structure leave more work to be done later when we change to a new structure.
As such, this issue highlights pending refactorings that were not yet completed, due to the faster iterations we undertook to release the project sooner. Right now, before we expand further, is the most appropriate time to work on these changes, as they touch practically every file on the repo. There are not as many features built on top of the current structure to make changing it too difficult, and all subsequent additions to the project will benefit from it.
Pull requests created to address these changes should not change public-facing features. (Note that this does not include the API as it's not part of our public API yet.)
This, thus, basically includes commits marked with the
refactor,chore,build,test, andstyleconventional commit types (but nofeatorfixcommits must be present). These include:backendandsharedprojects that does not disrupt what's returned to the frontend;Tasks
Project
sharedpackage into separate packages, and move frontend and backend toapps(refactor: split shared into packages #50, Fixing the packges build and github workflows #55)shared(refactor: split shared into packages #50)eslint-plugin-prettierand leave formatting toprettier(Update ESLint configuration #54)@web/@serverto just@/, or add more useful aliases../../../../lib/in favor of@lib/webandserverin commands forfrontendandbackendconcurrentlyback for running frontend and backend with single commandInfrastructure
Shared packages
canvasFactorymodule (it's hacky to allow the same code to be imported in frontend and backend)(refactor: split shared into packages #50)
Backend
api/v1/prefix to justv1/- as the backend is already hosted in theapisubdomain (refactor: split shared into packages #50, Fix: Remove remaining /api prefixes from routes #56)song-browserandsongmodules to provide a single/songAPI path with flexible querying (feat: song search #59)data,pagination,error,success(true or false), andmessageFrontend
/imgsubfolder/publicfolderclient/path division from components'use client';directive at the top of each module already indicates whether something is a client component, rendering the nesting unnecessaryclient/folder and vice-versa) - it can easily lead to mistakes in component placementclient-onlyandserver-onlypackages for better enforcementpages/andcomponents/directories arbitrarily. Make this uniform