feat(BTable)!: add multisort capabilities

[dwgray]

Describe the PR

This is an update to #1835 with some progress.

• I believe I have multisort working and reasonably documented (and added in the 'complete example' that I've been using for testing.
• I've fixed the build errors, although there is an issue with BLink that I think might be a more fundamental problem. But I don't use BLinks in the router scenario, so don't have enough of a sense of what's going on to understand the intent.
• I have not fixed all of the tests. I believe there is a fundamental issue with how defineModel works that is breaking the tests and causing other issues.

---

On the defineModel issue, it looks like the model isn't getting defined as expected. I believe this may be the same issue that I saw in #1822 - According to the vue docs:

In dev mode, the compiler will try to infer corresponding runtime validation from the types. For example here foo: String is inferred from the foo: string type. If the type is a reference to an imported type, the inferred result will be foo: null (equal to any type) since the compiler does not have information of external files.

In dev mode I'm seeing errors like this: [Vue warn]: Invalid prop: type check failed for prop "modelValue". Expected Boolean, got Array for things like BFormCheckbox
And if I move the type declaration of BFormCheckboxProps into BFormCheckboxVue I get an error on the when using defineModel - `Duplicate key 'modelValue'. May cause name collision in script or template tag.

I've actually tried reverting back to useVModel and the tests still fail. Also trie reverting the versions of dependencies in package.json I must be misunderstanding something about how the system builds/works because I would expect the combination of those two actions to get back to passing tests.

---

On multisort, there were a couple of bugs in the existing implementation, and I'm not 100% certain that I kept the spirit of what @VividLemon intended. But I documented what I implemented, so hopefully, it's close enough and should be more obvious what the intent is if you want to move in a different direction.

The one thing I didn't do that I think might be worthwhile is to allow sortBy to be a single BTableSortBy value when multisort == false . I think that would be somewhat more ergonomic for a developer to consume.

Small replication

A small replication or video walkthrough can help demonstrate the changes made. This is optional, but can help observe the intended changes. A mentioned issue that contains a replication also works.

PR checklist

What kind of change does this PR introduce? (check at least one)

• Bugfix 🐛 - fix(...)
• Feature - feat(...)
• ARIA accessibility - fix(...)
• Documentation update - docs(...)
• Other (please describe)

The PR fulfills these requirements:

• Pull request title and all commits follow the Conventional Commits convention or has an override in this pull request body This is very important, as the CHANGELOG is generated from these messages, and determines the next version type. Pull requests that do not follow conventional commits or do not have an override will be denied

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[dwgray]

This is puzzling. I would have expected the tests that check for input and change events to start failing with #1825, which is when I removed the events from the code under test. But instead, all of the tests that are checking for emit are failing now. My first thought was that this was related to the useVmodel/defineModel changes that I noted in the [commit description(https://github.com//pull/1840#issue-2236507641). But there is something else going on specifically with the checkbox event tests.

I did just the package updates from this PR in a separate branch and the only tests that fail are the checkbox tests (and they fail in the same way).

I checked the changelogs for the three most likely suspects (vue-test-utils, vue, and vitest) and didn't see anything suspicious.

Releases · vuejs/test-utils (github.com)
core/CHANGELOG.md at main · vuejs/core (github.com)
Release v1.4.0 · vitest-dev/vitest (github.com)

Then I tried rolling them back explicitly and am still seeing the errors. I may be misunderstanding how to roll back packages - what I did was changed the version to the exact version we were previously using (without the '^') did a pnpm-install and then checked the pnpm-lock file to validate that it was showing the rolled back versions.

I logged the results of wrapper.emit() before and after the package updates on one test it('custom value checked checkbox emits change event when clicked', async () => {.

Before (and working):

{
  input: [ [ [Event] ] ],
  'update:indeterminate': [ [ false ] ],
  change: [ [ [Event] ] ],
  click: [ [ [MouseEvent] ] ],
  'update:modelValue': [ [ 'unchecked' ] ]
}

After (and failing):

{ click: [ [ [MouseEvent] ] ] }

In any case, I can fix these specific tests, by testing the model value after the click rather than the emit, but I'm worried that this is reflecting a deeper problem.

[VividLemon]

Some failing tests appear to be the result of https://github.com/search?q=repo%3Abootstrap-vue-next%2Fbootstrap-vue-next%20%3Ato%3D%22container&type=code being changed to whatever they are now.

At the moment, I'm unsure about some of the others.

Although, it appears that some other issues may be something to do with

Under the circumstance where the wrapper component (rendercomponentorskip) is NOT skipped, it will create a wrapper div. Which means the native input and change events wont bubble up. If it is skipped, they will bubble up. However, we somewhat want these native events to bubble. I assume someone somewhere could use the Event.

Custom components like BFormRadioGroup don't declare these, because there isn't really a purpose.

[VividLemon]

Related: capricorn86/happy-dom#1409

[VividLemon]

Closing -- commits pulled into #1842