feat(dev): Add oxlint and a CI workflow for fmt & lint#777
Conversation
a5ehren
changed the title
waffles-dev
left a comment
waffles-dev
left a comment
There was a problem hiding this comment.
I'm happy with changes to this one. Leaving final call to @TibixDev - he'll need to set up the branch rule anyway.
* Add oxlint for linting and type checking * Update prettier config to be aware of tailwind CSS * Add a CI workflow to run both on all PRs * Run both tools and accept all edits to get a good baseline
waffles-dev
left a comment
waffles-dev
left a comment
There was a problem hiding this comment.
I'm personally happy with changes, I think this helps to improve quality of the project for long term and that this is good to go as-is.
Waiting on feedback from Tibix - he'll have final say on this one.
waffles-dev
left a comment
waffles-dev
left a comment
There was a problem hiding this comment.
Hey, sorry for the long wait, Tibix has finally gotten around to taking a look - have some minor feedback
| () => winboat?.isUpdatingGuestServer.value, | ||
| isUpdating => { | ||
| if (isUpdating === true) { | ||
| novncURL.value = `http://127.0.0.1:${getActiveHostPort(winboat?.containerMgr!, CommonPorts.NOVNC)}`; |
There was a problem hiding this comment.
Can you revert this one? If the ! fails we'd rather have the crash and fix a bug that could cause it to be null, rather than silently return.
There was a problem hiding this comment.
(Also, for now, revert any similar instances, if any, of this change in other files)
| } | ||
|
|
||
| app.whenReady().then(() => { | ||
| void app.whenReady().then(() => { |
There was a problem hiding this comment.
Tibix has asked if we can disable whatever rule is enforcing the explicit void and revert the relevant changes.
| "esModuleInterop": true, | ||
| "lib": ["esnext", "dom"], | ||
| "types": ["vite/client"] | ||
| "types": ["vite/client", "web-bluetooth", "w3c-web-usb"] |
There was a problem hiding this comment.
what were these added for?
There was a problem hiding this comment.
revert changes to this file for now - this'd need to be considered in a separate PR
| this.appUsageCache[newApps[appIdx].Name] = newApps[appIdx].Usage; | ||
| for (const app of newApps) { | ||
| app.Usage = this.appCache.find(cachedApp => cachedApp.Name == app.Name)?.Usage || 0; | ||
| this.appUsageCache[app.Name] = app.Usage; |
There was a problem hiding this comment.
can this one also be submitted as a separate PR?
does a rule need to be temporarily disabled to allow the old loop to stay in place? - if so, then please do so and enable the rule in the new PR
2 participants
The project did not have any mechanism to enforce format settings or code quality, so this PR does: