Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: major project structure update #1564

Merged
merged 14 commits into from
Oct 4, 2024
Merged

Conversation

setchy
Copy link
Member

@setchy setchy commented Sep 30, 2024

Major project structure update applying

Main updates include:

  • split code into main and renderer src components for clear separation of duties
  • update main to use TypeScript and split into smaller files (main, menu, icons, utils, updater)
  • improve webpack configs, including code minimizing for production builds
  • use webpack plugins for templating html and extracting css
  • use webpack plugins to copy twemoji svgs into final build with updated EmojiText implementation to avoid reading directly from node_modules path.
  • move all non-core dependencies from dependencies to devDependencies
  • rename jest test suites to match new folder structure

…n, and improve webpack process for bundling

Signed-off-by: Adam Setch <[email protected]>
@github-actions github-actions bot added dependency Dependency updates refactor Refactoring of existing feature labels Sep 30, 2024
@@ -21,13 +21,12 @@ export const EmojiText: FC<IEmojiText> = ({ text }) => {
ref.current.innerHTML = twemoji.parse(text, {
folder: 'svg',
ext: '.svg',
callback: (icon: string, options: TwemojiOptions, _variant: string) => {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No longer need to pluck these out from the node_modules within the asar bundle 🚀

…n, and improve webpack process for bundling

Signed-off-by: Adam Setch <[email protected]>
…n, and improve webpack process for bundling

Signed-off-by: Adam Setch <[email protected]>
…n, and improve webpack process for bundling

Signed-off-by: Adam Setch <[email protected]>
…n, and improve webpack process for bundling

Signed-off-by: Adam Setch <[email protected]>
…n, and improve webpack process for bundling

Signed-off-by: Adam Setch <[email protected]>
@setchy setchy marked this pull request as draft September 30, 2024 22:16
…n, and improve webpack process for bundling

Signed-off-by: Adam Setch <[email protected]>
@setchy setchy marked this pull request as ready for review September 30, 2024 22:37
Signed-off-by: Adam Setch <[email protected]>
…n, and improve webpack process for bundling

Signed-off-by: Adam Setch <[email protected]>
Signed-off-by: Adam Setch <[email protected]>
Signed-off-by: Adam Setch <[email protected]>
@bmulholland
Copy link
Collaborator

Any way to split this into chunks, to ease review? :)

@setchy
Copy link
Member Author

setchy commented Oct 1, 2024

Any way to split this into chunks, to ease review? :)

Yep - can be done...

env:
GH_TOKEN: ${{ secrets.github_token }}
- run: pnpm prepare:remove-source-maps
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Why do we need to remove the source-maps?
  2. Why is this one after the package and on others before the package?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good eyes re: 2 - that's an oversight on my part. Updated

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

re 1 - it was within the https://github.com/electron-react-boilerplate/electron-react-boilerplate example. My assumption that they remove the source maps so that the packaged+minified code cannot be reconstructed. Not a big deal for an open source project

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly, and it may help with tracing back bugs reported by users, however I am not sure how we can help users provide these off the top of my head 🤔

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, not too sure. I think our exception handling and electron-logger should be catching most user reported issues.

That said, would it be best for now to skip minimizing source code?

Copy link
Member

@afonsojramos afonsojramos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good! A few comments, but I think this may make it easier for us to switch from Webpack to Vite in the future 👀

Comment on lines -103 to 134
"@discordapp/twemoji": "15.1.0",
"@electron/remote": "2.1.2",
"@primer/octicons-react": "19.11.0",
"axios": "1.7.7",
"class-variance-authority": "0.7.0",
"clsx": "2.1.1",
"date-fns": "4.1.0",
"electron-log": "5.2.0",
"electron-updater": "6.3.4",
"final-form": "4.20.10",
"menubar": "9.5.0",
"nprogress": "0.2.0",
"react": "18.3.1",
"react-dom": "18.3.1",
"react-final-form": "6.5.9",
"react-router-dom": "6.26.2",
"tailwind-merge": "2.5.2",
"ts-loader": "9.5.1",
"typescript": "5.6.2",
"update-electron-app": "3.0.0"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feels weird that a lot of these can go in the devDependencies. Are you sure about nprogress, class-variance-authority, axios, @primer/octicons-react, @discordapp/twemoji, clsx, tailwind-merge and react-final-form?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems to be fine - in fact more probably can be moved actually.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can validate in the release candidate testing

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's even the difference between the two, in this case? I feel like it makes sense for e.g. a server, where you have execution mode and development mode. But for Gitify, the code that's run in execution mode is all post-build, and the dev dependencies are used to make the build. So the package.json is never actually executed in a non-dev mode. If that makes sense?

@@ -1,4 +1,4 @@
import { type ClassValue, clsx } from 'clsx/lite';
import { type ClassValue, clsx } from 'clsx';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you find a reason for needing the non lite one? I had set that one because we didn't need the base one.

Copy link
Member Author

@setchy setchy Oct 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No specific use-case, but was having issues with the new tsconfig and importing clsx/lite.

import baseConfig from './webpack.config.main.base';

const configuration: webpack.Configuration = {
devtool: 'source-map',
Copy link
Member

@afonsojramos afonsojramos Oct 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this in the prod one? - I suppose this relates to us deleting them on the build step. We might keep it if we want to, depends on what gets decided in #1564 (comment)

Copy link
Member Author

@setchy setchy Oct 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤷‍♂️ - was just following the erb template

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO source-maps make sense if we have a centralized error reporting. That's probably why the template has it. Since we don't have exception tracking, there's nowhere to send the source maps, so I don't think it's necessary.

src/renderer/index.html Outdated Show resolved Hide resolved
@setchy setchy merged commit 992be09 into main Oct 4, 2024
10 checks passed
@setchy setchy deleted the refactor/major-overhaul branch October 4, 2024 19:08
@setchy setchy added this to the Release 5.15.0 milestone Oct 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependency Dependency updates refactor Refactoring of existing feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants