Post milestone3m

[SharonStrats]

This PR expands the v2 web component surface (new Button/Select/Combobox/PhotoCapture and introduces a manifest-driven build/export pipeline to keep webpack entries and package.json subpath exports in sync, alongside a few widget/login behavior fixes and new unit tests.

Changes:

• Introduces scripts/component-manifest.mjs + sync/watch scripts, updates webpack config to consume manifest entries, and updates package.json exports/scripts accordingly.
• Adds new Lit-based components (actions/button, forms/select, forms/combobox, media/photoCapture) with READMEs and unit tests; reorganizes v2 layout/auth component entrypoints.
• Fixes/adjusts runtime behavior: prevent concurrent checkbox updates, normalize dropped URIs and stop propagation on DnD, broaden drop targets for attachments, and harden getUserRoles() for missing session/current user.

• don't forget to bring back in user preference messaging Ticket Error cannot fetch your preferences when not logged in #464
• checkbox fix for Ticket Double click on checkbox breaks it. #124
• discuss /*/ changing to login-button instead of loginButton etc.

[Copilot]

Pull request overview

Copilot reviewed 41 out of 53 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (2)

src/widgets/forms.js:168

• This section appears to have a structural/syntax break: after the try/catch block the file continues with a stray parameter list (container, already, subject, ...) which looks like the start of another function signature, implying missing braces/accidental deletion around the end of the group renderer and start of the Options renderer. As-is, this likely makes forms.js invalid JS and will prevent the module from loading.
  README.md:433
• The prompt history entry includes an absolute local filesystem path (/Users/sharon/...). This isn’t portable and will be confusing for other contributors; please change it to a repo-relative path (e.g. src/media/media-capture.ts).

* Claude Sonnet 4.6: Make the drop down as a list under the input field and enlarge the pop up, make it higher, adjustable to fit the drop down. And make the drop down arrow area larger

* GPT-5.4 Model: can you wire up the keyboard interactions and aria attributes for Select?

* GPT-5.4 Model: Take the code from /Users/sharon/2025Dev/solid-ui/src/media/media-capture.ts and make it a web component. Make it work in forms as well as not. Make it configurable and follow LoginButton.

[Copilot]

Pull request overview

Copilot reviewed 41 out of 53 changed files in this pull request and generated 5 comments.

Comments suppressed due to low confidence (1)

README.md:433

• This prompt-history entry includes an absolute local filesystem path (/Users/...), which is not portable and can unintentionally leak developer machine details into published docs. Replace it with a repo-relative path (e.g., src/media/media-capture.ts) or omit the path entirely.

* GPT-5.4 Model: can you wire up the keyboard interactions and aria attributes for Select?

* GPT-5.4 Model: Take the code from /Users/sharon/2025Dev/solid-ui/src/media/media-capture.ts and make it a web component. Make it work in forms as well as not. Make it configurable and follow LoginButton.

[timea-solid]

@NoelDeMartin This is the latest work on components that we started. Check the branch. What do you think?

[NoelDeMartin]

Hey, I've taken a quick look at this and other PRs (SolidOS/profile-pane#284 and SolidOS/solid-panes#632).

Before I get into the specifics, here's some guiding principles for how I think we should work (let me know if you disagree with something!):

• Avoid reinventing the wheel.
• keep a single source of truth.
• Consistency > Opinion (I'd prefer doing something consistently even if I disagree with it, than allowing inconsistencies depending on individual developer opinions).
• These are rules of thumb, not hard rules. But we must have a very good reason to make an exception.

Having said that, here's some specific feedback:

UI/Components

I've noticed there is a lot of hand crafting of HTML and UI. I understand the decision to not use any framework (like React, Vue, etc.), but in the end what that means is that we're creating our own UI framework. That is a lot more work than using one of the existing solutions, and can potentially introduce a lot of complexity. I think we should be aware of that, and avoid it by being very consistent and follow some rules. The end goal should be, indeed, to "create our own framework". Not to end up with a bunch of JS scripts that each does things a different way.

With that, it seems like the "framework" we've decided to rely on is lit/lit-html. But there are still some parts of the code (both old an new) that create HTML manually (using createElement, setting attributes in JS, etc.). I would completely avoid that, if we're using lit/lit-html, let's use it everywhere.

There is also some inconsistencies with styling. Most of the code seems to rely on CSS classes, but there are some utility classes as well. We can be a bit lax here, but we should be very clear on what is "allowed" and what isn't in terms of classes. For example, I think behavioural classes like sr-only or hidden are fine. But classes like flex-column or align-left should be avoided completely.

Finally, I think the exporting/importing mechanisms could be improved. I see there is some component registry that is used to generate component bundles, etc. That can potentially become cumbersome and create issues, I think the bundles should be generated following the folder structure. Ideally, we wouldn't even have bundles, and rely on tree-shaking. But that may be a challenge with the current implementation (many imports rely on side-effects, such as components registration).

Dev tooling

Regarding the dev.ts script in some panes, I think we should actually create a separate package for that which can be reused in each pane. It seems like this "dev sandbox" is duplicated in every repository, and tweaked sometimes with diverging features. It'd be easier to produce a separate library, which may also be used for pane tests running in a real DOM (like Playwright).

Documentation and tooling

Given what I've mentioned about consistency, we should make sure that the conventions are kept. Ideally, they should all be enforced (or at least flagged) with tooling. But whatever can't be, we should document it. I'm not a huge fan of documenting exhaustively, because I think the code should be self-descriptive. But we should at least document the conventions that we agree on.

Nitpicks

Here's a list of things I've noticed, but won't get too much into the weeds (ask for clarifications if needed):

• Related files should be collocated (both styles and tests in the same component folder, not separate styles/ or tests/ folders).
• Accessibility is not a separate concern, it should be a core functionality of the code (so, not dedicated "accessibility" tests).
• I don't think we should keep a log of prompt usage history in the README, or anywhere in the codebase. Instead, we should use Co-Authored-By in commits together with prompt details.
• We should use some existing i18n solution, rather than export plain strings from src/texts/.
• We should use Prettier or Oxfmt.

[m5x5]

I agree with all of your arguments. It would be nice to use Oxfmt, I really like the idea of having a unified toolchain.
To follow the value of keeping a single source of truth I think we should make sure the solid-ui repository contains all our base components and that the Storybook is up to date.

According to the design we should use Lucide Icons, I would suggest we use their library for icons as well.