Create Device Models Repository Client

[YoDaMa]

This includes the untested new code structure for the Device Models Repository Client, following closely to the architecture of the Python Models Repository Client (Azure/azure-sdk-for-python#17180)

It is currently untested, and likely has bugs. In addition the tests for Node.js are not complete and neither is the rollup configuration. Futher testing using karma must be conducted to validate browser compatibility, based on shimming the filesystem calls and other node specific utilities.

[check-enforcer]

This pull request is protected by Check Enforcer.

What is Check Enforcer?

Check Enforcer helps ensure all pull requests are covered by at least one check-run (typically an Azure Pipeline). When all check-runs associated with this pull request pass then Check Enforcer itself will pass.

Why am I getting this message?

You are getting this message because Check Enforcer did not detect any check-runs being associated with this pull request within five minutes. This may indicate that your pull request is not covered by any pipelines and so Check Enforcer is correctly blocking the pull request being merged.

What should I do now?

If the check-enforcer check-run is not passing and all other check-runs associated with this PR are passing (excluding license-cla) then you could try telling Check Enforcer to evaluate your pull request again. You can do this by adding a comment to this pull request as follows:
/check-enforcer evaluate
Typically evaulation only takes a few seconds. If you know that your pull request is not covered by a pipeline and this is expected you can override Check Enforcer using the following command:
/check-enforcer override
Note that using the override command triggers alerts so that follow-up investigations can occur (PRs still need to be approved as normal).

What if I am onboarding a new service?

Often, new services do not have validation pipelines associated with them, in order to bootstrap pipelines for a new service, you can issue the following command as a pull request comment:
/azp run prepare-pipelines
This will run a pipeline that analyzes the source tree and creates the pipelines necessary to build and validate your pull request. Once the pipeline has been created you can trigger the pipeline using the following comment:
/azp run js - [service] - ci

[rido-min]

The client should detect when the requested model-id does not match casing.

Eg, the next resolution should fail

const dmr = require("../../dist/index.js")
const dmrClient = new dmr.ModelsRepositoryClient()
main = async () => {
  const models = await dmrClient.getModels('dtmi:com:example:temperatureController;1')
  console.log(JSON.stringify(models, null, 2))
}
main().catch(e=>console.error(e))

[xirzec]

Good work! I'm happy with where this has landed, thanks for the quick turnaround in handling feedback. I replied to the open threads I saw, let me know if I missed anything.

[xirzec]

/cc @willmtemple for feedback on the samples workflow

[xirzec]

out of curiosity, what do you do when currentPlatform is "undefined"? Also curious if it should be the actual value undefined instead of the string

[YoDaMa]

right now there is no real use for currentPlatform, which is probably why I let the bug on uncalled functions through. It is used to create a default user agent string, but the service is unmanaged so there's really no user agent string processing right now. This is just a future-proofing step.

[xirzec]

UserAgentPolicy can take care of platform detection:

https://github.com/Azure/azure-sdk-for-js/blob/master/sdk/core/core-rest-pipeline/src/policies/userAgentPolicy.ts

It already grabs the platform, bitness, etc

[xirzec]

It's part of the default pipeline returned by createPipelineFromOptions:

azure-sdk-for-js/sdk/core/core-rest-pipeline/src/pipeline.ts

Line 433 in 3fcd69b

export function createPipelineFromOptions(options: InternalPipelineOptions): Pipeline {

Or you can make an empty one and add it in if you don't want the other default behaviors