[core-util] Migrate from mocha & karma to vitest #27551
Conversation
|
API change check APIView has identified API level changes in this PR and created following API reviews. |
| "plugins": ["@azure/azure-sdk"], | ||
| "extends": ["plugin:@azure/azure-sdk/azure-sdk-base"], | ||
| "rules": { | ||
| "@azure/azure-sdk/ts-package-json-module": "off" |
There was a problem hiding this comment.
since we're not building tests anymore, this changed our dist-esm paths and the rule here doesn't account for it.
xirzec
requested review from
witemple-msft,
deyaaeldeen,
ckairen and
jeremymeng
as code owners
| browser: { | ||
| enabled: true, | ||
| headless: true, | ||
| name: "chromium", | ||
| provider: "playwright", | ||
| }, |
There was a problem hiding this comment.
I wonder, could we disable security in the browser to get around CORS for testing like what we do now with karma or should we just bail on doing that?
There was a problem hiding this comment.
There might be a way to pass those kinds of options, but do we have any SDKs currently that need that for their browser tests?
There was a problem hiding this comment.
See here. IIRC, we do that to run AAD tests in the browser but perhaps we shouldn't?
There was a problem hiding this comment.
Hm yeah I'm curious if this is needed for the kind of tests we normally do
There was a problem hiding this comment.
Although I wonder if there're cases where fine-grained control over bundling is needed, it is exciting that vitest abstracts a lot of the silly stuff needed to create those bundles so hopefully the majority of the libraries can migrate.
Also, could we vendor the testing command through dev-tool so we don't have to duplicate the config files and the dependencies in each library?
| "downlevel-dts": "^0.10.0", | ||
| "cross-env": "^7.0.2", | ||
| "eslint": "^8.0.0", | ||
| "inherits": "^2.0.3", | ||
| "karma": "^6.2.0", |
Packages impacted by this PR
@azure/core-utilDescribe the problem that is addressed by this PR
An experiment to migrate away from mocha and karma to vitest. This eliminates the need for a browser bundle as vitest uses the test source files directly.
Update: I have also created a small plugin to avoid needing to add additional browser mappings for testing