fix: configure ESLint environments and resolve CI lint errors

[shishir-21]

What was fixed

• Configured ESLint to correctly handle Node.js and Service Worker environments
• Resolved CI-breaking no-undef errors (process, clients)
• Cleaned up regex escape warning in User model

Result

• npm run lint now passes (warnings only, no errors)
• CI pipeline unblocked

No functional changes.

[shishir-21]

Hi @gbowne1 👋

I’ve resolved all ESLint environment and no-undef errors (Node / Service Worker globals), and npm run lint now passes with warnings only.

The remaining CI failures are due to no-console warnings being treated as blocking in CI. There are no functional or syntax issues left.

Before proceeding further, I wanted to confirm your preference:
1️⃣ Should I remove / suppress console.log statements to make CI fully green?
2️⃣ Or is it acceptable to merge with warnings only for now?

Happy to adjust based on your guidance. Thanks!

[gbowne1]

@shishir-21 @Ved178

Its okay to merge with warnings this round but now we have a situation where #84 #72 #81 needs fixed and the PR for it merged ASAP as an emergency fix before we get more PRs and also now theres a pile of PRs again.

Please re review that PR and all other open PRs and I'll merge accordingly

[shishir-21]

@gbowne1
Hello ,
The branch currently contains a file named .env.example: (with a trailing colon),
which causes git pull/rebase to fail on Windows due to NTFS filename restrictions.
Could you please rename it to .env.example?
Happy to update my PR once it’s fixed upstream.

[Ved178]

Hey I resolved the head ref issue with #84 so it's ready to be merged in my opinion.
Will take a look at the other two PRs

@shishir-21 , PR #84 resolves the trailing colon issue.

[shishir-21]

@gbowne1

Thanks for the clarification 👍
Understood — I’ll review the emergency fix PR and the other open PRs shortly.

[gbowne1]

@Ved178 @shishir-21

Let's go back and re review all open PRs especially the ones which got rebased.

I have a funny feeling that if we don't #78 soon were going to keep have this same issue

[gbowne1]

@shishir-21
I checked out this change locally for testing and review for merge

This correctly addressed most of the CI issues as far as I can tell.

Approving this PR for merge and merging pending merge of the .env issue PR #84 and further approved review by collaborators and maintainers.

Let's look at doing #78 very soon.

Thanks for the opportunity to review your PR and for your contribution to this project

[gbowne1]

I would also review the pr by @glenjaysondmello #87 as it seems to cause the CI to go green

👀

[gbowne1]

@shishir-21 @Ved178 @glenjaysondmello @abhisheksingh1204

I merged the fixes. Another rebase? The latest merge as of today should fix the CI.

Let's try and get in the last of the PRz and re review. We will need the PR adding going live and chat before we start any refactoring

[Ved178]

Approving this, changes look good and I think it should resolve the lint errors.

[gbowne1]

@Ved178

The run shown below failed due to missing and or dependency not installed during the run.

I think this is an artifact. The package-lock got fixed in a recent merge.

Maybe a rebase? Even though it shows no merge conflicts.

@shishir-21 @glenjaysondmello @EdoAbarca @Haseebx162006

[gbowne1]

I think we could

Run npm install locally (not npm ci)

Commit the changes to package-lock.json.Push the changes

This is due to missing items from package.json not ending up in package-lock.json
re-run the CI

[shishir-21]

@gbowne1
Thanks for the clarification 👍

I’ll run npm install locally (not npm ci) to regenerate the package-lock.json, commit the updated lockfile, and push the changes to fix the dependency mismatch.

I’ll update the PR shortly and re-trigger CI.

[gbowne1]

Thanks. package-lock.json in version control is kinda dangerous especially if multiple contributors touch it.

I prefer keeping package-lock.json local only and ignored same with node_modules (they both get created on install anyway). There's pros and cons to commit them to the repo.

[shishir-21]

@gbowne1
Understood

Since package-lock.json is not intended to be version controlled, it looks like CI might still be using npm ci, which requires the lockfile.

Should we update the CI workflow to use npm install instead of npm ci?

[gbowne1]

I think so. But again there's caveats to both ways. I guess that we just see where the dust settles.

I'd leave it the way it is now till we can get to a clean CI with what we have right now

[shishir-21]

@gbowne1

The CI is currently failing because it runs npm ci, which requires a committed package-lock.json.

Since package-lock.json is not version controlled, npm ci will continue to fail.

We’ll need to either:

1.) Commit package-lock.json, or

2.) Update CI to use npm install instead of npm ci.

Let me know which direction you'd prefer and I’ll update accordingly.

[gbowne1]

@shishir-21

Well, let's stick with npm

package_lock.json is in .gitignore though.. lines 34 => 36

[shishir-21]

@gbowne1

Since package-lock.json is currently ignored in .gitignore, npm ci cannot work because it requires a committed lockfile.

To keep the lockfile ignored, the CI workflow would need to use npm install instead of npm ci.

Otherwise, we would need to remove package-lock.json from .gitignore and commit it.

Let me know which approach you'd like and I’ll update accordingly.

[gbowne1]

Well, it still keeps getting committed and/or changed even though it's been ignored by .gitignore.. So 🤷‍♂️

I'd like to remove it from .gitignore L# 34=>36 then recommit it and whatever other fixes needed so that what we have now works properly.

[shishir-21]

@gbowne1

Resolved all ESLint and Prettier issues. CI pipeline now passes successfully.

[gbowne1]

@shishir-21

Yes looks like everything passed.

Hopefully it stays this way.. but maybe we merge this next in line?

[shishir-21]

@gbowne1

Thanks! Yes, all lint and CI issues are resolved.
Happy to merge when you're ready.

[gbowne1]

@shishir-21

Well.. 🤷‍♂️

Another merge broke this yet again.

Had more merge conflicts which I resolved

Now the CI here fails again

[shishir-21]

@gbowne1

Closing this PR due to complex rebase conflicts.
Opened a clean replacement PR: #