* restarting dev server between each error test
* re-enabling the test on Linux CI
* trying separate describe() suites per error test
* narrowed the issue down, disabling for more investigation
* not: removing unrelated whitespace change
* fix: filter out falsy integration from telemetry
Falsy integrations are now ignored in `@astrojs/telemetry`
This error should no longer occur,
```ts
error Cannot read properties of null (reading 'name')
at file:///workspaces/bundle/node_modules/.pnpm/@astrojs+telemetry@0.1.2/node_modules/@astrojs/telemetry/dist/events/session.js:53:117
...
```
* ci: add tests for optional integrations
* ci: add changeset
* fix(@astrojs/telemetry): count number of optional integrations in use
* ci: add test for counting the total number of optional integrations in use
* ci: update changeset
* chore: make the changes @tony-sull sugested
* revert(@astrojs/webapi): mod.d.ts -> a4c78b5: [ci] format
* ci: remove `@astrojs/webapi` patch change
* chore(@astrojs/telemetry): remove totalIntegrations payload field
* fix(@astrojs/telemetry): add optional integrations field
* ci: add changeset
* Adding support for base64 encoded responses in Netlify Functions
* chore: add changeset
* removing the regex check for a more simple header-based check
* nit: cleaning up the readme a bit
* Remove redundant hydration scripts
* Prebuild the island JS
* Fix build
* Updates to tests
* Update more references
* Custom element test now has two classic scripts
* Account for non-default exports
* Restructure hydration directives
* Move nested logic into the island component
* Remove try/catch
* Update MarkdownInstance type
The return of the `default` function includes the same `frontmatter`
data as the parent object, merged with the `astro` data. The inclusion
of that frontmatter type was previously not recognized by TS, and fell
back to a `Record<string, any>`. This change persists the more accurate
type, as the runtime code does.
* fixup! Update MarkdownInstance type
(This change is what I'd personally do, but I don't really know how you
expect people to use `MarkdownContent` in practice, or if there is some
deeper benefit you wish to exploit by leaving it as an interface instead
of a type.
* feat(integrations): support optional integrations
By making integration optional, Astro can now ignore null or undefined Integrations instead of giving an internal error most devs can't read/won't understand.
This also enables optional integrations,
e.g.
```ts
integration: [
// Only run `compress` integration in production environments, etc...
import.meta.env.production ? compress() : null
]
```
* ci: add tests for optional integration
* docs: add changelog
