-
Notifications
You must be signed in to change notification settings - Fork 7
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
It's time to replace Gulp
#56
base: Maslow-Main
Are you sure you want to change the base?
Conversation
how does this interact with the upstream project? are they also doing similar
work? What are they looking to migrate to?
would it be possible to split this into two steps
1. eliminate the gulpisms (which should be acceptable upstream)
2. make the actual transition from gulp to something else
David Lang
…On Thu, 14 Nov 2024, md8n wrote:
Date: Thu, 14 Nov 2024 15:54:37 -0800
From: md8n ***@***.***>
Reply-To: BarbourSmith/ESP3D-WEBUI
***@***.***>
To: BarbourSmith/ESP3D-WEBUI ***@***.***>
Cc: Subscribed ***@***.***>
Subject: [BarbourSmith/ESP3D-WEBUI] It's time to replace `Gulp` (PR #56)
We're stuck on `gulp` v4, and the upgrade path is painful. More importantly is that `gulp` is effectively abandonware.
In reality we need to ditch `gulp` and its way of doing things with something better.
Right now, the thing that is 'better' is also much more comprehensive, and built on the knowledge from the last several years of how to do JS/TS based projects. And that is [bun](bun.sh)
This PR shifts over to bun, replacing all of the gulpisms along the way.
As much as possible, plain js/ts techniques are used, the idea is that things should just work, even if bun was not the tech chosen.
You can view, comment on, or merge this pull request online at:
#56
-- Commit Summary --
* First Steps
* Merge branch 'Standardize_Maslow_String_Usage' into gulp_down_the_bun
* Basic working, but very broken
* Merge branch 'Maslow-Main' into gulp_down_the_bun
-- File Changes --
M bun.lockb (0)
M package.json (18)
A serve.ts (48)
A tsconfig.json (27)
M www/docs/modal.html (401)
M www/index.html (124)
M www/js/SPIFFSdlg.js (7)
M www/js/UIdisableddlg.js (3)
M www/js/alertdlg.js (9)
M www/js/app.js (9)
M www/js/calculatesCalibrationStuff.js (5)
M www/js/camera.js (2)
M www/js/commands.js (23)
M www/js/config.js (5)
M www/js/confirmdlg.js (2)
M www/js/connectdlg.js (20)
M www/js/constants.js (8)
M www/js/controls.js (10)
M www/js/creditsdlg.js (2)
M www/js/files.js (91)
M www/js/grbl.js (13)
M www/js/http.js (4)
M www/js/inputdlg.js (2)
M www/js/language/de.js (2)
M www/js/language/en.js (2)
M www/js/language/es.js (2)
M www/js/language/fl.js (2)
M www/js/language/fr.js (2)
M www/js/language/hu.js (2)
M www/js/language/it.js (2)
M www/js/language/ja.js (2)
M www/js/language/pl.js (2)
M www/js/language/ptbr.js (2)
M www/js/language/ru.js (2)
M www/js/language/tr.js (2)
M www/js/language/uk.js (2)
M www/js/language/zh_CN.js (2)
A www/js/languages.js (55)
M www/js/logindlg.js (5)
M www/js/macrodlg.js (5)
M www/js/maslow.js (56)
M www/js/modaldlg.js (23)
M www/js/numpad.js (247)
M www/js/passworddlg.js (5)
M www/js/preferencesdlg.js (8)
M www/js/printercmd.js (41)
M www/js/restartdlg.js (5)
M www/js/scanwifidlg.js (5)
M www/js/settings.js (7)
M www/js/setupdlg.js (5)
M www/js/statusdlg.js (5)
M www/js/tablet.js (194)
M www/js/tabs.js (2)
M www/js/translate.js (52)
M www/js/updatedlg.js (7)
M www/js/util.js (31)
M www/js/wizard.js (2)
-- Patch Links --
https://github.com/BarbourSmith/ESP3D-WEBUI/pull/56.patch
https://github.com/BarbourSmith/ESP3D-WEBUI/pull/56.diff
|
It doesn't, largely. So obviously there's significant issues with that.
Their most recent changes look to be around 3 months ago, and they aren't touching this stuff at all.
I believe that they are not looking at migration at all. My best guess is that it has fallen into the "too-hard basket"
That's what I've been exploring. There's a lot of embedded gulpisms here. More importantly, as an aspect of that, there's a lot of code that was bad practice when it was done, and has gotten worse with time. And which is effectively entrenched because of gulp. The key consideration here, is that gulp is, to all intents and purposes, abandonware. It will not be updated in any meaningful way. To make matters worse, webui is not even on the latest version of gulp, and the version that it is on has some significant incompatibilities with the latest version, such as you can call it the latest version. Another way of phrasing all of the above is that there is an enormous technical debt with webui. And that fastest way of paying down that technical debt is ... don't ... the least painful way is to cut our loses and move on with whatever works best now, which is bun. |
The fear I have is us going off in one direction when upstream goes of in
another direction (we already have a rather significant fork in the firmware
side of it)
But if they aren't doing any work on the problem, then it doesn't hurt for us to
work on it. I would only ask that you try to submit your gulpism removal
upstream, not just work on the maslow fork.
David Lang
…On Sun, 17 Nov 2024, md8n wrote:
Date: Sun, 17 Nov 2024 16:05:41 -0800
From: md8n ***@***.***>
Reply-To: BarbourSmith/ESP3D-WEBUI
***@***.***>
To: BarbourSmith/ESP3D-WEBUI ***@***.***>
Cc: David Lang ***@***.***>, Comment ***@***.***>
Subject: Re: [BarbourSmith/ESP3D-WEBUI] It's time to replace `Gulp` (PR #56)
> how does this interact with the upstream project?
It doesn't, largely. So obviously there's significant issues with that.
> are they also doing similar work?
Their most recent changes look to be around 3 months ago, and they aren't touching this stuff at all.
> What are they looking to migrate to?
I believe that they are not looking at migration at all. My best guess is that it has fallen into the "too-hard basket"
> would it be possible to split this into two steps 1. eliminate the gulpisms (which should be acceptable upstream) 2. make the actual transition from gulp to something else
That's what I've been exploring. There's a lot of embedded gulpisms here. More importantly, as an aspect of that, there's a lot of code that was bad practice when it was done, and has gotten worse with time. And which is effectively entrenched because of gulp.
The key consideration here, is that gulp is, to all intents and purposes, abandonware. It will not be updated in any meaningful way. To make matters worse, webui is not even on the latest version of gulp, and the version that it is on has some significant incompatibilities with the latest version, such as you can call it the latest version.
Another way of phrasing all of the above is that there is an enormous technical debt with webui. And that fastest way of paying down that technical debt is ... don't ... the least painful way is to cut our loses and move on with whatever works best now, which is bun.
|
With regard to this I'm pretty sure that they aren't going in any direction.
I am used to doing the kind of massive code changes necessary when dependencies have been "left to rot" for too many years. Past experience tells me to get the work done first and then selectively take elements out of the new work for PRs back in the old. The reason for this is that it is usually too difficult to identify an appropriate transitional path, until you've already finished the journey. I'm already seeing patterns of what can be done for smaller PRs that could be submitted to the upstream codebase. But I'll continue with what I'm doing for now. |
md8n wrote:
> I would only ask that you try to submit your gulpism removal
upstream, not just work on the maslow fork.
I am used to doing the kind of massive code changes necessary when dependencies have been "left to rot" for too many years. Past experience tells me to get the work done first and then selectively take elements out of the new work for PRs back in the old. The reason for this is that it is usually too difficult to identify an appropriate transitional path, until you've already finished the journey.
I'm already seeing patterns of what can be done for smaller PRs that could be submitted to the upstream codebase. But I'll continue with what I'm doing for now.
Sounds good.
David Lang
|
We're stuck on
gulp
v4, and the upgrade path is painful. More importantly is thatgulp
is effectively abandonware.In reality we need to ditch
gulp
and its way of doing things with something better.Right now, the thing that is 'better' is also much more comprehensive, and built on the knowledge from the last several years of how to do JS/TS based projects. And that is bun
This PR shifts over to bun, replacing all of the gulpisms along the way.
As much as possible, plain js/ts techniques are used, the idea is that things should just work, even if bun was not the tech chosen.