refactor: split shared into packages #50
Conversation
…adjusting exports
…e unused imports across various files
… unused imports across the frontend
tomast1337
added
enhancement
… up unused imports in auth and song services
…ture for backend and frontend
…add dependency in package.json
…istency across song components
…an up unused imports in auth, song, and user modules
…g, sounds, and thumbnail packages
…song, and sounds packages to use glob pattern for improved test discovery
There was a problem hiding this comment.
Looks great! Thank you for working on these changes =)
Some extra things (besides the review comments) we gotta make sure are working before merging:
- Update VSCode workspace file, test running etc. to reflect the new project structure
- Update GitHub Actions to reflect the new project structure
There was a problem hiding this comment.
As the app packages are now prefixed with @nbw/, it could be a good idea to rename them to just @nbw/frontend and @nbw/backend in package.json?
There was a problem hiding this comment.
We had originally decided to leave build.ts in the root of the project, as it was depended upon by both the frontend and the backend. With the new project structure, doesn't it belong in one of the different packages we created?
(Adding @nbw/sounds as the one single global workspace dependency looks a bit weird to me, haha :) )
There was a problem hiding this comment.
For consistency, could we rename the build commands to use frontend and backend too, like the package names?
There was a problem hiding this comment.
As a result of introducing separate packages, first-party package imports have been grouped with third-party ones (see this file as an example). The @nbw/ group should be added as a local package group in ESLint - I'll look up how we can do this again :)
There was a problem hiding this comment.
I believe the backend package should belong in apps too?
There was a problem hiding this comment.
Following the rest of the project's structure, this file could be moved to the source file's path, and renamed to stats.spec.ts (as we'll likely add test files for the other modules in there)
There was a problem hiding this comment.
To avoid all the repetition, would it be possible to use a shared tsconfig.json using extends with these common package configurations?
There was a problem hiding this comment.
The separate .gitignore files may not be necessary, in case the root's package.json already takes care of them
No description provided.