### Packages impacted by this PR
@azure/ai-form-recognizer
@aazure/event-hubs
@azure/data-tables
### Issues associated with this PR
N/A
### Describe the problem that is addressed by this PR
Just bumping the version of these packages which depend on core-tracing 1.0.0-preview.14 to instead depend on 1.0.0
### Packages impacted by this PR
@azure/data-tables
### Issues associated with this PR
- #20213
- #5607
### Describe the problem that is addressed by this PR
Now that @azure/core-tracing@preview.14 is out, and hopefully the last version
before GA, we need to upgrade a few packages in order to dogfood both the
upgrade experience and the usage of these packages with the new instrumentation package.
My goal was to upgrade one AMQP package and a few HTTP packages in addition to
core-rest-pipeline to collect feedback.
Upgrading Data Tables now allows us to start using the new APIs in a client package.
### Provide a list of related PRs _(if any)_
- #20240
* cleanup tests
* First set of tests
* Table client tests
* Table Service
* Node Tests
* Browser Tests
* Fix lint
* Update recordings
* Fix lint
* go after a new version of the test-proxy that dumps the testmismatch
* newer proxy version with additional logging. need to pr back this into sdk/tools
* return test-proxy to align with main. there are conflicts that are not present in the investigation branch
* Update recorded client
* Update proxy tool build
* fix format
* Revert proxy tool version
* Ignore headers
* Fix format
* Use HeaderlessMatcher
* Fix format
* Fix tests
* Remove un needed config
Co-authored-by: scbedd <45376673+scbedd@users.noreply.github.com>
Thanks to #19530 we have a new HttpClient that uses Fetch. Currently, we can't make it the default because of recorded tests. However, we'd like folks to be able to try it out, which this PR makes possible.
The solution here is for tests that are dependent on XHR to pass in a custom HttpClient to allow the previous recordings to be used until we can migrate those packages to the new recorder.
* configureClientOptions core-v2
* configureClientOptions
* & Record<string, unknown>
* Replicate https://github.com/Azure/azure-sdk-for-js/pull/19920 for core-client-rest
* formatting
* Replicate https://github.com/Azure/azure-sdk-for-js/pull/19920 for core-client-rest
* format
* attestation test fixes
* format
* more format
* format
* more recorder.configureClientOptions
* migration guide
* more format
* mixed-reality update
* attestation simplification
* more fixes
* changelogs and gettingstarted docs
* format
* format
* changelog
* tables ci - test-proxy variable
* env.SAS_CONNECTION_STRING test fix
* sort imports
* [storage,tables] Update `signedExpiry` to computed value
instead of hard-coded one which has expired and failed test resource deployments
* Missed copying `baseTime`
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
Preserve original casing of HTTP header names when iterating over stored name/value pairs and optionally when converting HttpHeader collections back to JSON.
Fixes#18367
Reported in #18033.
Basically did a bulk find+replace everywhere. Things _seem_ to be working OK, but wouldn't be surprised if there's something somewhere I've missed, or somewhere where I've replaced something I shouldn't.
I've split the rename of PerfStress -> Perf and runAsync -> run into two commits for ease of review :)
* Support manually handling continuationTokens
* Use PageSettings and update version
* Update samples and page type
* Address PR Comments
* Undo changes to generated samples
* Fix format
## 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
* Remove leftover recordings whose tests had been deleted
* Move test secrets into file so we can suppress the file, instead of suppressing using the unstable hashes
* Update suppression list
* update rush.json
* lock file
* package.json, rollup and tsconfig
* src file
* test
* add recorder.stop call
* set http
* set protocol to http
* core-rest-pipeline draft
* storage test
* keep only the storage test
* lock file
* update package.json
* recorder-new
* lock file
* undefined to null
* remove target es5
* add a guide with starter steps
* testing-recorder-new
* lock file
* types - recorder-new
* import urlBuilder from core-http
* disclaimer in the guide
* comment out the test in recorder-new
* testing recorder-new setup and test
* rest-pipeline 1.1.0
* lock file
* "versionPolicyName": "test" and sdkType
* karma.conf
* fix package.json
* update test to take sas url
* omit readme checks for testing-recorder-new, recorder-new
* lock file from master
* lock file and readmes
* remove TEST_MODE variable
* update readme with temp-location
* resources update
* skip runnign in ci
* update package.json
* remove console.logs and fix queue name
* fix browser mappings
* index.browser.ts and console.logs
* remove .olg from clean command
* test file with logs
* update readme
* update readme to reflect additional environment variables that must be set
* login steps
* lock file
* test file
* Copying the recordings saved in the container
* remove console logs
* "@azure/data-tables": "^12.1.2"
* dependencies
* rename test file
* core-v2 recorder first draft
* core-v2 node test works
* karma-conf fix
* uri -> url
* update tests
* refactor core-v1 and core-v2 recorder clients
* refactor common code between core-v1 core-v2 and node and browser
* renames and underscore removals
* typings -> types
* address feedback
* RecordingStateManager
* lock file
* lock file
* lock file from master
* lock file
* recorder-new package test skipped
* delete commented test file
* Update sdk/test-utils/testing-recorder-new/README.md
* empty test file
* lock file
* add link descriptions
* Daniel's feedback
* Update sdk/test-utils/recorder-new/README.md
Co-authored-by: Scott Beddall <45376673+scbedd@users.noreply.github.com>
* Scott's feedback
* Addressing Will's feedback
* Add tslib
* RecordingState
* lock file
* currentState
* lock file
* docker cp
* remove lib from tsconfig
* more feedback
* utils file and base tests
* update error message
* initial set of tests
* Add copyright headers
* No need of the if checks
* both Test_Modes
* Append ${testMode} mode:
* karma conf and tests
* Daniel's new found love - npm run clean move from prebuild to build
* Added many many comments for Daniel 🐱👤
* lock file
* package renames
Co-authored-by: scbedd <45376673+scbedd@users.noreply.github.com>
* 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
- Our convention now is to use `types`.
- Some packages output type definition files into `types` directory but the `clean` scripts still use `typings`.
* [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
* test-proxy in options
* recordingClient from recorder-new
* getRecordingClient public method
* blobServiceClient uses getRecordingClient
* not browser
* checkpoint
* add login steps in getting started
* checkpoint
* NaN bug fix
* remove temp-location note
* logs and minor tweaks - some bug at playback
* remove logs
* update options
* rushx format
* fix sendRequest
* removing unneeded details
* getting started and removing console.log
* improve type readability
* do not redeclare static PerfStressTest.recorder
* rushx format
* simplified tsconfig
* create project
* create project
* simple and batch tests
* core-v2 prototype with addPolicy
* readem disclaimer
* Address Mike's feedback
* rename recorder to testProxyHttpClient
* rename
* fix build failures
* rushx format
* fix test
* readme and getting started
* pnpm-lock file
* rename policy
* swap v1 and v2
* bug fix
* update getting started
* update getting started
* rushx format
* changelog
* Scott says no need to login anymore
* Add workflow in comments
* description
* pnpm-lock file
* RecordingStateManager
* URLBuilder -> URL
* rushx format
* readme
* lock file
* Update sdk/test-utils/perfstress/src/options.ts
Co-authored-by: Mike Harder <mharder@microsoft.com>
* configureClientOptionsCoreV1 & configureClient
* update types
* comments
* getting started
* testProxyClient is not set, please make sure the client/options are configured properly.
* if (!request.headers.get("x-recording-upstream-base-uri")) set upstream uri
* Add undici
* Investigate hanging docker or image (#33)
* getting started
* testProxyClient is not set, please make sure the client/options are configured properly.
* if (!request.headers.get("x-recording-upstream-base-uri")) set upstream uri
* Add undici
* checkpoint
* make core-v2 client identical to core-v1 except for sendReq
* update error message
* formatting
* TestProxyHttpClientV1 depends on V2
* rushx format
* Mike's final minor feedback
* For corev1, extend TestProxyHttpClient instead of DefaultHttpClient
* update tests file
* no instaceof checks
* move to http.request
* Jeff's feedback
* CachedProxyClients
* keep clients on the test class
* bad merge conflict resolution
* Update sdk/test-utils/perfstress/GettingStarted.md
* final minor feedback
* remove CachedProxyClients wrapper
Co-authored-by: Jose Manuel Heredia Hidalgo <joheredi@microsoft.com>
Co-authored-by: Mike Harder <mharder@microsoft.com>
This PR adds missing changelog entries for the times we
- updated tracing dependencies to use the GA version of OpenTelemetry
- updated to target ES2017
**Context:**
When querying the Tables service we have an option to disable automatic type conversion. This means that we would give users an object similar to what the service sends us. For example, an object with a Date property will be received like this, with an `@odata.type` metadata property
```json
{
"PartitionKey": "1",
"RowKey": "1",
"dateValue": "2020-09-17T00:00:00.111Z",
"dateValie@odata.type": "Edm.DateTime"
}
```
The SDK's automatic type conversion would use the metadata to give users a primitive Date type so the user would get the following object
```javascript
{
partitionKey: "1",
rowKey: "1",
dateValue: new Date("2020-09-17T00:00:00.111Z")
}
```
If `disableTypeConversion` is true in the list or get operations the sdk returns the Edm object instead of a primitive type
```javascript
{
partitionKey: "1",
rowKey: "1",
dateValue: {value: "2020-09-17T00:00:00.111Z", type: "DateTime"}
}
```
**Problem**
There are 3 types when the service never sends `@odata.type` metadata and just the value, these are int32, double, and string. Before this PR we would return the value instead of the EDM object since no @odata.type property was found. This causes an inconsistent experience.
**Fix**
When `disableTypeConversion` is true, return an EDM object instead of the value by inferring the EDM type, in the case of the string is straightforward. In the case of int32 and decimal, JavaScript treats both as `number` so we need to inspect the value looking for decimal places to decide whether to use `Edm.Int32` or `Edm.Decimal`.
**Note:**
There is a limitation with this approach, and it is that JavaScript drops decimals if they are `0` for example, `1.00` would be represented as `1`. With these changes, such cases would always have an Edm type of `Int32`
In #15938 we exposed the `allowInsecureConnection` option to allow
connections to the service over HTTP instead of HTTPS. However, even
if a table client was created allowing insecure connections, we would
still require a secure connection when submitting a batch transaction,
since the implementation of batch operations interact with the
pipeline directly. We now record if the client was created allowing
insecure connections and thread that information along when creating
requests for batch operations.
With this change, you can now submit batch transactions to storage
emulators, which commonly run over HTTP instead of HTTPS.
Fixes#15854
## 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
* displayed links as a list rather than a single line
* appconfiguration\Readme: displayed links as a list rather than a single line
* confidential-ledger-rest/README.md: display links as list
* container-registry/README.md: display links as list
* cosmos/README.md: display links as list
* iot-device-update/README.md: display links as list
* eventgrid/README.md: display links as list
* event-hubs/README.md: display links as list
* eventhubs-checkpointstore-blob/README.md: display links as list
* formrecognizer/README.md: display links as list
* identity/README.md: display links as list
* iot-modelsrepository/README.md: display links as list
* keyvault-admin/README.md: display links as list
* keyvault-certificates/README.md: display links as list
* keyvault-keys/README.md: display links as list
* keyvault-secrets/README.md: display links as list
* ai-metrics-advisor/README.md: display links as list
* mixedreality-authentication/README.md: display links as list
* monitor-query/README.md: display links as list
* purview-catalog-rest/README.md: display links as list
* purview-scanning-rest/README.md: display links as list
* quantum-jobs/README.md: display links as list
* search-documents/README.md: display links as list
* schema-registry/README.md: display links as list
* schema-registry-avro/README.md: display links as list
* service-bus/README.md: display links as list
* storage/storage-blob/README.md: display links as list
* storage-blob-changefeed/README.md: display links as list
* storage-file-datalake/README.md: display links as list
* storage-file-share/README.md: display links as list
* storage-queue/README.md: display links as list
* data-tables/README.md: display links as list
* ai-text-analytics/README.md: display links as list
* video-analyzer-edge/README.md: display links as list
* web-pubsub/README.md: display links as list
* web-pubsub-express/README.md: display links as list
* core-lro/README.md: display links as list
* changed from the word master to main
* changed the word master to main
* another update to the final reandme to change the word master to main
* Update README.md
fixed a type in the link
* Update sdk/anomalydetector/ai-anomaly-detector/README.md
Co-authored-by: Deyaaeldeen Almahallawi <dealmaha@microsoft.com>
Co-authored-by: Deyaaeldeen Almahallawi <dealmaha@microsoft.com>
In order for Tables to connect to Azurite and Storage emulator, the client needs to accept `allowInsecureConnection`. Also when using the emulator connection string shortcut, setting it by default.
## What
- Update `@azure/core-rest-pipeline` to 1.1.0 from beta
- Update dependencies to the latest version
- Update everyone to the same version of `@azure/core-tracing`
## Why
Now that we used the CAE capabilities added in core-rest-pipeline in both container registry and key vault it's time to GA this version! It also unblocks our efforts to get everyone upgraded to the latest core-tracing (and OTel by extension) versions.
* Migration Guide
* Update sdk/tables/data-tables/MigrationGuide.md
Co-authored-by: Christopher Scott <chriscott@hotmail.com>
* Update sdk/tables/data-tables/MigrationGuide.md
Co-authored-by: Christopher Scott <chriscott@hotmail.com>
* Update sdk/tables/data-tables/MigrationGuide.md
Co-authored-by: Christopher Scott <chriscott@hotmail.com>
* Update sdk/tables/data-tables/MigrationGuide.md
Co-authored-by: Christopher Scott <chriscott@hotmail.com>
* Update sdk/tables/data-tables/MigrationGuide.md
Co-authored-by: Christopher Scott <chriscott@hotmail.com>
* Fix typos
* Apply suggestions from code review
Co-authored-by: Matt Ellis <matt.ellis@microsoft.com>
* Address comments
Co-authored-by: Christopher Scott <chriscott@hotmail.com>
Co-authored-by: Matt Ellis <matt.ellis@microsoft.com>
As we are ending the support for IE 11, this PR remove doc and test logic that
handle IE.
- Remove commented polyfill from karma configs
- Remove IE compatibility section from Stroage README files
- Remove IE specific logic from storage tests.
- Remove Storage TODO comments for IE.
* format
* run format on core-client-rest
* Re-generate and Custom serialization for ACL
* format
* update readme
* format readme
* Update changelog
* set swagger package-version
* Update format script
* Fix test and update changelog
* update recorder and recordings
* fix test and changelog
* use deterministic date for test
* update format
* fix lint
* return await
* Update TSDoc samples
* Add additional samples to TSDoc
* Add createIfNotExists and deleteIfExists. Loosen Entity output type
* Rename property tableName to name
* update samples
* Cleanup models
* more type cleanup
* remove un-used request options
* Remove next prefixed properties from public types
* Add date samples
* Update batch sample
* Publish samples
* Remove ifNotExist and ifExist
* 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.
* [dev-tool] Experimental samples publish command
* Updated template samples structure
* First generation of template samples
* Update to ts-node 9 and use transpilation mode for speed.
* Many improvements and fixes.
- Fixed several bugs with generation.
- Added environment variable analysis.
- Refactored modules for code organization.
- Added azsdk- JSDoc tags for weighting and ignoring samples.
- Made almost all illogical situations yield errors instead of warnings.
* Rework text analytics
* Fixed a bug in the README template saying something about the Template package
* Regenerate text analytics samples
* Consistency changes to dev-tool/register
* Updated TA and Template package.json
* Fixed a couple of file name rendering bugs in the template
* Added API ref link override and regenerated Template samples
* Format
* Fix broken link
* Made typescript version reflect dev-tool ts dependency
* Revert weird change to cosmosdb package.json
* Alpha sort template deps
* Added MIN_SUPPORTED_NODE_VERSION
* Tweaked default tsconfig.
* Use version 1.0.0 instead of 0.1.0
* Pull sample generation info types into their own module.
* Added resource creation link generation.
* Regenerate template samples
* Regenerate text analytics samples
* Regenerate text analytics samples
* Regenerate template samples
* Fix bug in TA samples
# Problem
`no-invalid-this` makes sure uses of `this` are valid (see [docs](https://eslint.org/docs/rules/no-invalid-this) and [implementation](8984c91372/lib/rules/utils/ast-utils.js (L900))). However, uses of `this` are rampant in our test suites because this is how mocha unit tests are structured, the Mocha context can be accessed only through `this`.
# Fix
So instead of disabling `no-invalid-this` in our test suites, this PR tags functions that reference `this` with `@this` and that satisfies the rule requirements (see [docs](https://eslint.org/docs/rules/no-invalid-this)).
# Discussion
It could be argued that this work just replaces one comment annotation with another so we did not really solve the underlying problem. However, the inherent problem lies in how mocha itself works and there is nothing we can do other than probably migrating to another framework that is more sane/type-safe. One minor improvement we get is we now have slightly less syntactic overhead because we need to tag just the function instead of individual lines in its body that violate the rule.
# Trade-offs
Pros:
- function tags are less than line tags
Cons:
- whitelisting one more tag with the tsdoc linter that our devs need to learn about
- still having rampant tags everywhere
Fixes https://github.com/Azure/azure-sdk-for-js/issues/11404
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.
* [EventGrid] Update to {core-client,core-rest-pipeline}@^1.0.0
* [EventGrid] Prepare for GA Release
- Update version to `4.0.0` from `3.0.0-preview.4`. The move to
`4.0.0` is to align our version with the new SDKs for EventGrid from
the other languages.
- Update CHANGELOG.md
* Revert "[core v2] prepare for GA release (#14170)"
This reverts commit 0e06e728d6.
* [Core v2] Revert GA version bump and release another preview
* Not releasing core-xml
* Update release date
* [core v2] prepare for GA release
- core-rest-pipeline. Update version and release date
* - core-xml. update version and release date
* - core-client. update version and release date
Creating a `tracingOptions` property on PipelineRequest and using createSpan internally rather than starting spans directly.
Also, allows callers to use createSpanFunction() without a package prefix or namespace (needed for core-http and lower level libraries).
* Fix docs and case-insensitive CS
* Hide top query option
* Keep default empty object
* address feedback
* Fix connection string
* test cs with = in value
- 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.
* Update live test templates to use matrix generation
* Update sdk live tests to use matrix generation, cloud config stages
* Fix live test matrix filter parity errors
* Remove matrix filters. Opt-in most tests to samples and min/max testing
* Fix post step template parameter in monitor live tests
* Filter dependency version for live tests that don't support it
* Only publish test results for browser and node tests
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.
This PR removes our dependency on the unmaintained package "karma-remap-istanbul" and replaces it with a smaller karma plugin ("karma-sourcemap-loader") that allows karma-coverage to load source maps from the disk correctly.
I tested and confirmed that the generated coverage data has the correct source TS files.
* [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
# Status quo
Some of our documentation comments are [TypeDoc](http://typedoc.org/guides/doccomments/) and some of them are JSDoc with type description in the comments even though it is for typed TS code.
# Standardization
I decided the best way to go about this is to migrate to [TSDoc](https://github.com/Microsoft/tsdoc) and enforcing it using the [tsdoc eslint plugin](https://www.npmjs.com/package/eslint-plugin-tsdoc).
Pros:
- TSDoc is a proposal to standardize the doc comments used in TypeScript code, so that different tools can extract content without getting confused by each other’s markup.
- It is being developed at Microsoft, with the TypeScript team.
- It has an ESLint plugin that enforces it and will error when it sees unsupported tags (e.g. `@memberof`, `@class`, `@constructor`, `@type`, etc).
Cons:
- It is still in early stages (adoption is ongoing though, e.g. it is being used by the API extractor tool).
- TSDoc != TypeDoc (the tool we currently use for generating our documentation). However, TypeDoc plans to officially support TSDoc in v1.1 (see https://github.com/TypeStrong/typedoc/issues/1266).
# Notable tag changes
- `@ignore` is a JSDoc tag and was used in conjunction with `@internal`. These tags were needed because [TypeDoc does not yet support documenting only definitions exported by the entry point](https://github.com/TypeStrong/typedoc/pull/1184#issuecomment-650809143) and still documents everything exported from all files. I removed `@ignore` because [`@internal`](https://tsdoc.org/pages/tags/internal) only should suffice
- `@ignore` when used alone is replaced with TypeDoc's [`hidden`](http://typedoc.org/guides/doccomments/#hidden-and-ignore). EDIT: I replaced `@ignore` with [`@hidden`](https://github.com/TypeStrong/typedoc/releases/tag/v0.12.0) because the TypeDoc version used for `docs.microsoft.com` is v0.15.0 which does not support `--stripInternal`. After, they upgrade, I will remove all `@hidden` tags.
- `@summary` is gone because it is not part of TSDoc or TypeDoc
This PR applies the changes to packages that respect our linting rules. Ones that do not yet will be migrated later when we start fixing their linting issues.
Here are vanilla examples of TypeDoc 0.18.0 (version used by our EngSys) after the changes here as a sanity check:
- random method:
![typedoc](https://user-images.githubusercontent.com/6074665/102302881-f6186380-3f27-11eb-8cc6-93e4c8f7d42d.PNG)
- a class constructor that used to have type information in the documentation comments:
![constructor](https://user-images.githubusercontent.com/6074665/102357078-f8a4a880-3f7b-11eb-92d1-c086ecc39c0b.PNG)
# `@hidden` works the same way as `@ignore`
Here are the list of documented functions generated by `TypeDoc v0.15.0` for the text analytics package and there is no function that was marked `@hidden`, e.g. `combineSuccessfulAndErroneousDocumentsWithStatisticsAndModelVersion`
![image](https://user-images.githubusercontent.com/6074665/102426196-e018aa80-3fdc-11eb-8b69-1ac265391fad.png)
# Things to consider
- Our documentation must be generated using the TypeDoc flag [`--stripInternal`](http://typedoc.org/guides/options/#stripinternal)
- Should we add a `docs` npm script to our `package.json`s (similar to [Cosmos's](2424b74f02/sdk/cosmosdb/cosmos/package.json (L60))) so that we can see how our docs are generated as we write our comments?
Fixes https://github.com/Azure/azure-sdk-for-js/issues/3027.
* 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
Fixes#12646
Tables service supports ns precision DateTime however JavaScript doesn't. As part of entity deserialization, whenever we get a property with type Edm.DateTime we parse it into a JavaScript Date object, which can lead to losing precision.
To fix this we need to disable the default deserialization for Edm.DateTime and give the user an "edm" object, similar to what we do for Guid and Int64
```typescript
{
partitionKey: "p1",
rowKey: "r1",
blahblah: {type: "DateTime", value:"the date"}
}
```