-
Notifications
You must be signed in to change notification settings - Fork 258
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
Conversation
…n, and improve webpack process for bundling Signed-off-by: Adam Setch <[email protected]>
@@ -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) => { |
There was a problem hiding this comment.
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]>
…n, and improve webpack process for bundling Signed-off-by: Adam Setch <[email protected]>
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]>
Signed-off-by: Adam Setch <[email protected]>
Any way to split this into chunks, to ease review? :) |
Yep - can be done... |
.github/workflows/release.yml
Outdated
env: | ||
GH_TOKEN: ${{ secrets.github_token }} | ||
- run: pnpm prepare:remove-source-maps |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Why do we need to remove the source-maps?
- Why is this one after the package and on others before the package?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 🤔
There was a problem hiding this comment.
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?
Signed-off-by: Adam Setch <[email protected]>
There was a problem hiding this 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 👀
"@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" |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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'; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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', |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
Signed-off-by: Adam Setch <[email protected]>
Major project structure update applying
Main updates include:
main
andrenderer
src components for clear separation of dutiesmain
to use TypeScript and split into smaller files (main, menu, icons, utils, updater)dependencies
todevDependencies