Current focus

[ChristopherVR]

Welcome back @yunfeizhu , and thanks for offering to keep going.

So figured I'll open a GitHub discussion for now - I don't have the capacity to setup a whole discord server yet lol - unless you have one I don't mind joining.

So like I mentioned in the other post we now have "one" structure for every product. The viewers (pptx, docx, xlsx, visio) now live in this repository, and I'm bringing them onto one structure: sharing more code, following the same conventions, and releasing from one pipeline. The roadmap and structure plan have the details.

The PowerPoint viewer is still the outlier here and ultimately I didn't start correctly when I initially created it. Word, Excel and Visio build their UI once as web components (ooxml-ui plus each product's elements), and each framework binding is a thin wrapper - though this is not yet in a "perfect" state because ideally the thin wrappers still hooks, references, signals, etc. as required by the framework in a bit more of a natural flow "native" to the library / framework. In viewers/pptx, every binding (React, Vue, Angular, Svelte, vanilla) is still hand-crafted, so each fix has to land five times. docs/ooxml-ui-plan.md tracks which pptx components have already moved to ooxml-ui and which are still to come.

Word, Excel and Visio. Most of my own time is going into fidelity and editing for these three. OpenTeams and the Office suite launcher are mostly me experimenting at this stage, not a priority.

The most valuable work right now is getting the PowerPoint viewer onto the shared web-component model. Either of these would help a lot:

Migrating pptx-viewer UI into web components.
and/or PowerPoint fixes and fidelity. Rendering or editing gaps against PowerPoint itself, ideally with a sample deck and a screenshot from PowerPoint as the reference.

Word, Excel and Visio contributions are welcome too.

If you rather want to focus on something else I'm not too fussed so let me know!

[yunfeizhu]

Hey Christopher, thanks for all the work you’ve put into this over the past few days! It’s great to see the different viewers coming together under a shared structure.

For now, I’ll take some time to get familiar with the ooxml project and its codebase, and start by tackling a few small issues along the way. Happy to keep the conversation going here!

[yunfeizhu]

@ChristopherVR One thing I've run into while working on recent PRs: CI takes a long time for each iteration, especially the multi-framework browser tests. Some runs also fail on issues unrelated to the PR. For example, in #38 the React table test failures reproduce on unmodified upstream code, and the full fork CI flags formatting in an unchanged Visio document.

Do you have a recommended way for contributors to handle this? Is there a smaller set of checks we should run first, and how should we report or handle known upstream failures without expanding a focused PR? I'd like to keep validation thorough while reducing the time spent repeating long CI runs.

[ChristopherVR]

Hey @yunfeizhu yeah this is tedious and I'm open for suggestions here but its mainly my own fault as I've been doing trunk based development.

I think I need to improve a bit on my end so I'll see what I can do to stop pushing broken code lol. I'm open for suggestions if you have a better way of fixing this, one aspect I'm thinking of is adding a pre-push hook (locally on my end only) to run as much of the affected tests as I can.

[yunfeizhu]

@ChristopherVR A local pre-push hook sounds useful. I already run relevant unit/browser regressions, builds, typechecks, formatting and lint manually before pushing. Reusing ci-plan.mjs for the hook's affected checks could keep local and CI scopes consistent.

One improvement on the contributor side might be letting manual CI accept an upstream base SHA and a scoped/full option. Currently manual runs force a full-repository check; my fork run for #38 took about 54 minutes and included unrelated viewers. Matching the PR scope could avoid those extra checks, while keeping full runs for nightly/final validation. The five-framework PPTX browser matrix would still be substantial.

For confirmed baseline failures, I'll keep comparison logs separate from focused fixes. For uncertain browser failures, we need the base and PR tested in the same CI environment before calling them unrelated; a local pass alone isn't enough.

[ChristopherVR]

@yunfeizhu sweeet thanks for the ideas.

So changes made in total main (5f73df1...ee23407):

• bun run verify: reuses ci-plan.mjs to run locally what CI would for your commits: lint, format, typechecks, affected tests and the touched viewers' checks. Browser suites are opt-in with --browser. I now run it from a local pre-push hook.
• Scoped manual CI: a manual run takes scope: changed plus a base commit, so it only checks what your branch reaches. Full runs stay the default.
• on_base: runs the same scoped checks on the base commit, so you can confirm a failure is already upstream in the same CI environment.

CONTRIBUTING.md and AGENTS.md describe all of this.

[yunfeizhu]

@ChristopherVR Thanks for implementing these! I'll sync the latest code and use bun run verify before pushing, scope: changed for fork CI, and on_base to check suspected upstream failures in the same CI environment. I'll keep confirmed baseline failures separate from focused PR fixes and share feedback after trying the new workflow.

[coletebou]

Hi @ChristopherVR, I'm Cole. I've been working on ooxml for the last few days, mostly the Excel side so far, with some Word fixes too. I'd like to build on the whole suite, so I'm glad to help across all of it: the PowerPoint move onto the shared components (I saw that's what helps most right now), Word, Excel, Visio and Teams. If a mail and calendar app is ever on the roadmap, I'd be keen to help build that too.

You said you'd join a Discord server if someone had one, so I set one up for the project: https://discord.gg/zT7kveRPXb

It has announcements and a releases feed, a help forum with a tag per app, a contributing channel, and a channel for each of Excel, Word, PowerPoint, Visio, Teams and the core. New members pick the apps they care about when they join, and the rules point at the repo's Code of Conduct and SECURITY.md. I'd like to hand it over to you as owner once you're in, so it's yours to run however you like. If you'd rather keep everything in Discussions, that's completely fine too.

What I have open or coming, each from main and one concern each:

• perf(xlsx): fit row heights without rebuilding grid metrics per row #112 perf(xlsx): row auto-fit no longer rebuilds the grid metrics for every row (writing 1M cells went from 216 s to 4.5 s).
• fix(docx): save text edits in tables whose rows differ in cell count #111 fix(docx): text edits in tables whose rows have different cell counts can be saved.
• Coming once they finish review on my fork:
  • a fix for the bun run verify failures in unrelated Visio tests that @yunfeizhu asked about above (Vitest 5.0.5 skips the per-file setup files under --changed, so the DOM hygiene stops running between files);
  • CSV import options modelled on Excel's automatic data conversion settings, with a warning when a conversion changes data;
  • load limits a caller can raise;
  • row and column edits that no longer clone the whole sheet for undo.
• One I'd like your view on first: comparing two workbooks (values, formulas, formats, sheets, names, tables, conditional formats), like Excel's Spreadsheet Compare. It's about 2,500 lines with tests, so I can split it up or start with an issue if you prefer.

If you have a list of what you'd most like help with in each product, point me at it and I'll work from there.

[coletebou]

thanks for merging all of those, and for fixing the #125/#128 conflict yourself, that one was on us. sorry for the ci pileup earlier today, ill keep it to a couple at a time from here. the follow up fixes for the content controls and protected forms are up as #166 and #167, next up is more of the powerpoint panes moving onto the shared components