Migration to Vue 3, Completion of Google provider, fixes for vulnerable packages

[ericfitz]

Summary:
This change is primarily to update the dependency on Vue 2 to Vue 3. It also includes updating or replacing a number of vulnerable packages that were used with Vue 2, with Vue 3 compatible equivalents.

As of this pull request, there are no vulnerable run time dependencies, although some vulnerabilities are present in packages that are only used at build time.

Finally, this change includes complete support for Login with Google and Google Drive.

This change was made with extensive AI support - Sonnet 3.7 via Claude Code and Roo Code.

Closes #444
Closes #1173
Closes #1159
Closes #905
Possibly makes #1080 moot

Description for the changelog:
Migrated vue2 dependency to vue3. Updated vulnerable runtime packages. Added Google provider support.

Declaration:

• appropriate unit tests have been created / modified
• functional tests created / modified for changes in functionality
• any use of AI has been declared in this pull request

Other info:
I tried to preserve the spirit of all the existing tests, but many of them needed significant refactoring as they were DOM based and Vue 3 DOM significantly differs from Vue 2 DOM.

Thanks for submitting a pull request!
Please make sure you follow our Code of Conduct
and our contributing guidelines

[ericfitz]

@lreading I would really appreciate it if you'd see if you can resolve the packaging issues.

I modified the npm clean script to remove node_modules/ and I added a clean:lock script to remove the package-lock.json files. I also added npm install:all and npm ci:all to do installation/recreate package-lock.json, and to test clean-install.

I've reverted my use of npm workspaces and now am back to managing packages at the root, in td.server, and in td.vue.

I've tried to correctly declare all os-dependent packages, and all optional packages, as such. I have a feeling that the "package-lock out of sync" errors are not actually that they're out of sync, it's that the github actions server for some reason doesn't think a package is optional, which was optional when I built package-lock.json. I don't know how to resolve that.

I've synced all my changes into the merge.

Thank you!
Eric

[ericfitz]

gentle ping @lreading

[ericfitz]

Feel free to clone my branch and make a pull request. I've made a few updates since you last checked.

[lreading]

Sorry for the delay! When I run npm install, the package-lock.json does not get updated on my Ubuntu machine anymore. I also don't see any errors when running npm ci (locally) 🤔

The only thing I can really think of right now is completely regenerating the package-lock from my ubuntu machine and seeing what happens? I'll open a PR soon, feel free to merge if you think it's worth trying. I'm not certain it will work, and if I'm being honest I'm pretty stumped by this one!

[ericfitz]

@lreading thank you for looking into this, it was definitely a mystery but I figured it out. Npm can incorrectly tell you that package-lock.json is out of sync with package.json, when package-lock is generated with --omit=["optional"] but that omit flag is not honored on the server running npm ci.

During the unit tests, the problem was that the eslint packages were marked as "optional" when they needed to be "development". I fixed that and all the unit tests are passing.

There is something wrong with whatever is running the smoke test. Instead of (or before) running "npm clean-install", it needs to run "npm install --legacy-peer-deps". The package-lock files are correct now; I don't believe there is anything I can do from this end to make the smoke test pass.

Since it's customary to run "npm clean-install" in continuous integration environments like pipelines, I didn't want to make that change, but I think that with different sets of packages for development vs. production, and with platform-specific dependencies like dmg-license and dmg-builder, and with the sheer number of packages and transitive dependencies, I don't think that any single static package configuration is going to work.

Let me know how you want to proceed.

Eric

PS You can interact with the code on the URL I sent you and do your own testing; I have enabled all the providers and switched Google to production mode so any Google ID can be used with it. There are still a couple of bugs in the diagram editor (dragging from an anchor to create a flow, for example), but I didn't want to pollute the merge anymore.

[jgadsden]

we use postintall because this is automatically applied by npm when running npm install
this save us from having to run npm run install:all
@lreading this may be why you are not getting the td.vue/package-lock.json file regenerated

[ericfitz]

It seems to not be working in the pipeline cases...

[ericfitz]

OK, so here's the status.

To fix all the package dependency issues, which fixed the unit and smoke test failures.

• I configured all platform-specific packages as optional and development
• I added "ignore=optional" and "legacy-peer-deps=true" to .npmrc and un-excluded .npmrc from git.
• I made the changes that Jon suggested regarding moving vue-only packages into td.vue.
• I left eslint at the project root (td.server needs it too) but added vue-specific configuration to an eslintrc in td.vue.
• The e2e tests now failed because optional packages weren't installed; I added npm install to the e2e tests and they pass now.

There is a single warning from CodeQL; I don't think it is an issue and I told CodeQL to ignore it but I'm diving back into it just to be sure.

There were some docker build errors.

• The first was a permissions issue related to creating the sboms. I fixed that by switching to root, running chown to fix permissions on the /app directory, and switching back to the node user.
• The second was missing optional packages, I fixed that by adding an npm install step.
• The third were some missing ruby gems; I added them to the gemfile.
• The fourth was persistent complaints from the IDE about not using tags (e.g. pinning specific container image by hash) and vulnerabilities in the container. I updated to a later debian based container image.

Now what's left is that Trivy is complaining about the vulnerabilities in the container image. I don't know if we can do an apt-get update in the container during the docker build process; I'm out of my depth there.

I'll look into the CodeQL bug but like I said, I don't think it's an issue. I would like to know what you want to do about the docker container vulnerabilities.

Best regards,
Eric

[ericfitz]

Hi @jgadsden and @lreading !

OK I have gone through the CodeQL warnings I got when I first submitted the pull request, about using a fixed token named "REDACTED" in auth.js.

What I'm doing there is ensuring that we can have robust debug logging while not leaking sensitive information to the logs. In auth.js I create "safe" copies of the OAuth structures that I want to stringify and log, and I replace the sensitive information with the word "REDACTED" in the "safe" copies, which are then logged. The "safe" objects are never used on the wire, so "REDACTED" is never used as a credential; I checked every instance in the code base.

Let me know how you want to proceed!

Eric