Proposal: Modernize Tooling & Dependencies (ESLint, Native Promise, lodash-es)

[hong4rc]

Proposal: Modernize Tooling & Dependencies (ESLint, Native Promise, lodash-es)

Hi @pcottle , I noticed that some of our current dependencies are quite outdated and receive little to no maintenance updates. I’d like to propose removing unnecessary libraries and gradually modernizing the stack to reduce technical debt, eliminate deprecation warnings, and make the codebase easier to maintain in the long term.

Below are a few libraries that I think we could consider removing or replacing. Could you please help review and advise which ones we should apply? I can then create separate PRs for each module accordingly.

---

1. Migrate from JSHint to ESLint

• JSHint is mostly in maintenance mode and is no longer considered an industry standard.
• ESLint has a much richer ecosystem and stronger community support.
• Better at catching potential bugs and enforcing consistent code quality.
• Supports auto-fix and integrates well with CI/CD pipelines.
• More flexible and scalable as the project grows.
• Migration can be done incrementally and does not need to block feature development.

---

2. Replace Q promises with native Promise

• Q is deprecated and currently produces deprecation warnings.
• Native Promise and async/await are fully supported in modern JavaScript.
• Removes an unnecessary dependency and helps reduce bundle size.
• Improves readability and makes async code easier to maintain.
• This change mainly affects syntax and should not impact business logic.

---

3. Migrate from underscore to lodash-es

• Underscore does not support tree-shaking effectively.
• lodash-es is ES module–based and designed to work well with tree-shaking.
• Currently, the codebase does not fully support tree-shaking yet.
• Vite is already installed but is currently only used to serve a port, without any bundle optimization improvements.
• Migrating to lodash-es prepares the codebase for future tree-shaking optimizations once Vite is properly applied.
• Migration effort is relatively small due to similar APIs.

---

Suggested approach

1. Review and agree on which items to apply.
2. Migrate incrementally, one module at a time.
3. Ensure test coverage before and after each change.
4. Create separate PRs to keep changes isolated and easy to review.

---

Expected benefits

• Reduced technical debt
• Fewer deprecation warnings
• Smaller and more optimized bundles (in the long term)
• Improved developer experience
• Easier long-term maintenance

Looking forward to your feedback 🙏

[pcottle]

Super supportive of all of this @hong4rc ! We might be able to even use claude code to accomplish some of this if you don't want to do it by hand (or if you were using AI earlier thats fine as well).

I truly wish this stack was more modern and I finished the react migration ages ago -- I feel like it would be easier for newcomers to contribute and GenAI tools to work with the codebase

[pcottle]

Alright removed the Q dependency in #1317! Codex was very impressive (it had a good idea to make a shim that had the same API vs try to replace all of the usages of it)