* chore(snc): widen vnode variable type in update-element.spec

this commit widens the types of multiple VNode variable instances to
`VNode | null` from `VNode`. in each of thsee usages, an old VNode
instance is instantiated as `null` for testing purposes to call
`updateElement`. since the old VNode can be `null` according to the
`udpateElement` function signature, this is considered to by a safe
operation (i.e. does not adversely affect the tests).

* chore(snc): init vnode with non-null values

the test that initializes these VNodes doesn't use these values stored
on the VNode, making this a safe operation in terms of the test

* review(ap): update typings

This adds some documentation to `src/dev-server/client/hmr-util.ts`
which was previously largely undocumented.

…and diagnostics (#4903)

* only set extension value if one exists

* handle nullish values when normalizing diagnostics

* don't return string if an extension doesn't exist

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

update the code reproduction description to be clearer,
specifically stating that we will likely close an issue if it
does not have a reproduction case

This fixes two snc errors related to the `.typesDir` property and then
additionally does a small refactor in `validate-dist.ts`.

add rollup and `@rollup` prefixed packages to one pull request when a
release goes out, to minimize the noise associated with a release

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

add a new abstraction layer to stencil's jest testing
configuration/running such that the version of jest is detected when
jest is run. based on the version that is detected, defer to the
correct piece of versioned infrastructure to setup and run tests.

in #4847, the directory
structure of the testing submodule was updated to look something like:
```
├── src/testing/jest/
│   └── jest-27-and-under
│       ├── jest-config.ts
│       ├── jest-environment.ts
│       ├── jest-preprocessor.ts
│       ├── jest-runner.ts
│       ├── jest-screenshot.ts
│       ├── jest-serializer.ts
│       ├── jest-setup-test-framework.ts
│       ├── node_modules/
│       ├── package.json
│       └── test
└── package.json
```

this commit introduces the following infrastructue to dispatch to
jest-27-and-under at runtime:

```diff
  ├── src/testing/jest/
  │   └── jest-27-and-under
  │       ├── jest-config.ts
  │       ├── jest-environment.ts
+ │       ├── jest-facade.ts                  <- Implements interface in `../jest-adapter.ts`
  │       ├── jest-preprocessor.ts
  │       ├── jest-runner.ts
  │       ├── jest-screenshot.ts
  │       ├── jest-serializer.ts
  │       ├── jest-setup-test-framework.ts
  │       ├── node_modules/
  │       ├── package.json
  │       └── test
+ ├── jest-apis.ts                            <- Interactions with Jest prior to knowing the version
+ ├── jest-facade.ts                          <- Interface  all `jest-facade` implementations should follow
+ ├── jest-stencil-connector.ts               <- Routes Jest logic through the correct `jest-facade` implementation
  └── package.json
```

Where:
- `jest-stencil-connector` - performs the detection of the current
version of jest - dispatching to the correct infrastructure via
`jest-facade` implementations
- `jest-facade.ts` - a file containing an interface to define the API by
which version-specific implementation can be loaded. the first
implementation for jest 27 and under is included in `jest-27-and-under/`
- `jest-apis` - a file containing typings for cases where the jest
typings are ambiguous, particularly for when we do not know what the
current version of jest is (yet)

the end result of this commit should be nothing to the end user (for
now). this work shall be used to help support jest v28+ in the near
future (dispatching the the correct version)

this commit updates the existing infrastructure for jest presets to move
them under version-specific directories (although there's just one such
directory at this time).

in doing so, the `jest-preset.js` file that was previously housed under
the `scripts/` directory now has the same dispatch behavior as the other
javascript files in the same directory (`git mv` was used to preserve
history of the original contents). this allows the correct version of
`jest-preset` to be selected at runtime when a user invokes jest.

`jest-preset.ts` contains the original preset with the following
changes:
1. it no longer uses CommonJS exports to make loading the file at
   runtime easier and compile-time compliant. it is worth noting that
   the contents of this file, in their previous location, would simply
   be copied to the output directory. now, they are run through the
   typescript compiler and placed in `testing/index.js` after the
   compiler has been built
2. `path` is now imported with an `import` statement, rather than a
   `require` statement as a consequence of point 1.

the resulting directory structure looks something like:

```diff
  ├── scripts/bundles/helpers/jest/
  │   └── jest-preset.js                      <- Now has same dispatch behavior as other files in this directory
  ├── src/testing/jest/
  │   └── jest-27-and-under
  │       ├── jest-config.ts
  │       ├── jest-environment.ts
  │       ├── jest-facade.ts
  │       ├── jest-preprocessor.ts
+ │       ├── jest-preset.ts                  <- Contains preset previously in `scripts/`, now as a module
  │       ├── jest-runner.ts
  │       ├── jest-screenshot.ts
  │       ├── jest-serializer.ts
  │       ├── jest-setup-test-framework.ts
  │       ├── node_modules/
  │       ├── package.json
  │       └── test
  ├── jest-apis.ts
  ├── jest-facade.ts
  ├── jest-stencil-connector.ts
  └── package.json
```

the jest facade interface and it's related impl have been updated to return
the correct jest preset

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

remove the `notice.md` file and its generation from the repository, as
it is no longer necessary to generate

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

)

This adds support for building form-associated custom elements in
Stencil components, allowing Stencil components to participate in HTML
forms in a rich manner. This is a popular request in the Stencil
community (see #2284).

The new form-association technology is exposed to the component author
via the following changes:

- A new option called `formAssociated` has been added to the
  [`ComponentOptions`](https://github.com/ionic-team/stencil/blob/06f6fad174c32b270ce239afab5002c23d30ccbc/src/declarations/stencil-public-runtime.ts#L10-L55)
  interface.
- A new `@AttachInternals()` decorator can be used to indicate a
  property on a Stencil component to which an
  [`ElementInternals`](https://developer.mozilla.org/en-US/docs/Web/API/ElementInternals)
  object will be bound at runtime.
- Using `@AttachInternals()` is supported both for lazy builds
  ([`www`](https://stenciljs.com/docs/www),
  [`dist`](https://stenciljs.com/docs/distribution)) as well as for
  [`dist-custom-elements`](https://stenciljs.com/docs/custom-elements).

The new behavior is implemented at compile-time, and so should result in
only very minimal increases in code / bundle size. Support exists for
using form-associated components in both the lazy and the CE output
targets, as well as some extremely minimal provisions for testing.

Documentation for this feature was added to the Stencil site here:
stenciljs/site#1247

Co-authored-by: tanner-reits <tanner-reits@users.noreply.github.com>