As discussed in #17076, we no longer have the need for the `docs` script in each of our packages. This PR removes this script and the related dev dependency on typedoc
This PR makes the following updates regarding the `nyc` dependency
- Update to v15 from v14 across all packages
- Updates to `@azure/monitor-opentelemetry-exporter` as it failed to run the tests with the updated nyc.
- Update the test scripts to use the js files in the dist-esm folder like all other packages instead of using the ts-node plugin.
- Update one of the tests for `@azure/monitor-opentelemetry-exporter` to use the right path for package.json file now that the tests are being run from the dist-esm folder.
Random set of live tests were triggered from this PR to ensure that nyc works as expected.
The failure for data-tables is an unrelated service side issue
Resolves#19232
## What
- Update API Extractor to the latest version (currently 7.18.11)
- Regenerate all API reviews by building all the packages
## Why
This is something we keep bumping into. First, we needed to upgrade API Extractor to allow us to re-export directly from
`@opentelemetry/api`. Then, it looks like we needed this to upgrade TypeScript to 4.4.
We are way behind on this version, and it's time to upgrade.
## Callouts
How noisy is this?! Here's what's happening - somewhere around 7.9 I think API Extractor improved the way it detects name
collisions with predefined globals. Things like KeyType, Response, etc.
If there's a clash, the generated API markdown file will rename <Item> to <Item_2> to make the name collision explicit.
Talking to folks on the team, and the poor souls that will be doing API Review approvals, we agreed that doing the upgrade
in one fell swoop is the way to go.
Resolves#9410
* Adding a note in the readme to release publicly
* rename `@azure/test-utils-recorder` to `@azure-tools/test-recorder`
* lock file
* delete recorder new file
* [Identity] Incrementing the package version
* setting samples to the last released version of Identity
* upgraded non-samples to 2.0.0-beta.6
* found a fix for the CI issue
* Increment package version after release of azure-synapse-managed-private-endpoints
* Increment package version after release of azure-synapse-access-control
* Increment package version after release of azure-synapse-artifacts
* Increment package version after release of azure-synapse-spark
* Fix package metadata and add missing version updates
Co-authored-by: azure-sdk <azuresdk@microsoft.com>
## What
- Remove `setTracer`
- Remove `NoOpTracer` and `NoOpSpan`
- Use Otel's APIs where possible (like when creating a no-op)
- Respect AZURE_TRACING_DISABLED environment variable
- Include test support for tracing utilizing OTel's trace API
- Avoid injecting invalid `tracerparent` header fields
## Why
- `setTracer` was added before OTel had their own implementation of a global tracer provider. For consistency with other libraries we should use the global tracer that was registered. It also leaves us out of the business of maintaining caches, global tracers, and other annoying things.
- These are no longer needed, since OTel has a recommended way to wrap a span in a NoOp. And, if no tracer provider was registered, a non-recording tracer (NoOp) will be created. All managed by OTel
- Finally, AZURE_TRACING_DISABLED is one of the env vars our guidelines say we should support
Resolves#16088Resolves#15730Resolves#10205
## What
- Adds warning filter to ignore known rollup warnings that are safe to ignore
- Ignore `this has been rewritten to undefined` in synapse
- Ignore circular dependencies in synapse
## Why
These are both known warnings, are safe to ignore, and add noise to the build output unnecessarily.
The first is totally safe to ignore:
```
var __spreadArray = (this && this.__spreadArray) || function (to, from) {
```
Is emitted from TypeScript in the OTel ESM and is safe to use.
The second is a known issue in OTel 1.0.0 that is not harmful at runtime.
Finally, we have precedent for doing the exact same thing in other packages like service-bus.
## What
- Update core-http to 2.0.0
- Update core-lro to 2.0.0
- Update packages to use latest version
## Why
This will support our last breaking change for core-tracing, and allow everyone to be on the same minimum version. This will also allow us to target ES2017 across the board.
## What
- Bump @opentelemetry/api to 0.20.0 in @azure/core-tracing
- Move all packages that are on core-http to the next core-tracing version
- Remove version collision check from the tracer cache
## Why
This is part of our effort to move everyone to OTel 0.20.0 - but we have to stage it due to a transitive dependency and a
breaking change in OTel. This PR updates core-tracing to use the latest OTel, fixes any breaking changes, and moves
packages that we can move to the latest version of core-tracing.
Once core-rest-pipeline 1.1.0 is GA'd we'll be able to move the rest of the packages over to the latest core-tracing as well.
Removing the version collision came out of an offline discussion after these changes were reviewed - since it's a common
source of pain and hasn't added much benefit (tracer conflicts incompatibility was never a problem) we decided to remove
that logic and always grab a unique symbol per OT compatibility.
## Callouts
The packages that are already on core-v2 will _not_ be upgraded at this time - we'll coordinate that with the GA of core-rest-pipeline 1.1.0
* Upgrading to opentelemetry 1.0.0 (rc.0)
Did a few things that made this MUCH easier.
Now that everyone is using the createSpan from @azure/core-tracing we
no longer need _every_ project to reference opentelemetry/api! That has
been removed as part of this PR.
Unfortunately, the leaky nature of JS means that packages still need to
worry about opentelemetry when they build their browser bundle for
testing. To make that simpler I've added a common function to dev-tool
that everyone can call in their rollup that will give them the correct
named exports. This is hooked up for everyone at this point, so the next
time something like this happens I should be able to control it
centrally.
Now for the API breaking changes that I had to fix:
- CanonicalCode is gone and is replaced with SpanStatusCode.
SpanStatusCode has a much smaller set of codes (literally: ERROR, OK
or UNSET) so that simplified most of the way we were handling setting
a span status on error.
- There is a new field (`tracingContext`) that contains `Context`. You
now pass a context, not a span, to indicate what your "parent" is.
You'll see this where I've removed `SpanOptions.parentSpan`. Mostly
it's a simple replacement.
I confirmed with the TypeScript team that patch releases should not introduce breaking changes. This PR uses tilde in TypeScript version we use so get the latest patch releases for v4.1.
- Making some changes to simplify the "duplicate" models that we're exporting to mirror the opentelemetry models (addresses feedback from @xirzec and @bterlson)
- Switch core-tracing back to the `-preview` version naming style. Changing it mid-stream like we did breaks internal tooling.
As part of prepping for the next release of OpenTelemetry we found some code patterns that were going to become a large maintenance burden for us, primarily around the parenting of spans. To make this easier I've removed as many duplicate implementation of createSpan and tried to centralize everything into core-tracing instead.
This won't completely remove changes needed for a newer version of OpenTelemetry but it'll eliminate one of the bigger bottlenecks.
* Increment package version after release of azure-synapse-monitoring
* Increment package version after release of azure-synapse-managed-private-endpoints
* Increment package version after release of azure-synapse-access-control
* Increment package version after release of azure-synapse-spark
* Increment package version after release of azure-synapse-artifacts
* [Docs] Upgrade typedoc to v0.15.2 to match that used by docs team
* standardize the docs script for cosmos, kv-admin, comm-common, and storage-internal-avro
This newly added command `docs` can help increase the quality of our documentation comments. It enables us to have a tight feedback loop on what is being generated as a documentation of our packages. I am pinning `typedoc` to v0.15.0 for now because this is the version being used for generating docs at `docs.microsoft.com`. This version should be updated when that team updates theirs.
Fixes https://github.com/Azure/azure-sdk-for-js/issues/12928
* upgrade TS version and fix compilation issues
* upgrade the linting parser version and fix new linting issues
* fix cosmos sample
* address feedback
* fix linting issues in formrecognizer tests
* use unknown instead of any across our code
* address more issues
* cleanup package.json in core-http
* revert noisy linting changes caused by vanilla eslint rules not TS aware
* allow the poller to have results of type void
* fixing samples
* fix keyvault-certificates' sample
Jeremy Meng
praveenkuttappan
Jeremy Meng
Jose Manuel Heredia Hidalgo
Will Temple
Jonathan Cárdenas
Ramya Rao
Maor Leger
Azure SDK Bot
Harsha Nalluru
Daniel Rodríguez
Chidozie Ononiwu
Deyaaeldeen Almahallawi
KarishmaGhiya
Richard Park
Jonathan Turner