azure-sdk-for-js/sdk/core/core-client-rest/vitest.browser.config.ts

15 строки
344 B
TypeScript
Исходник Обычный вид История

[core] Upgrade to ES-Modules for core (#26238) ### Packages impacted by this PR - @azure/abort-controller - @azure/core-auth - @azure/core-client - @azure-rest/core-client - @azure/core-http-compat - @azure/core-lro - @azure/core-paging - @azure/core-rest-pipeline - @azure/core-sse - @azure/core-tracing - @azure/core-util - @azure/core-xml - @azure/logger - @typespec/ts-http-runtime ### Issues associated with this PR ### Describe the problem that is addressed by this PR This migrates the core packages from a hybrid of CJS and ESM to an ESM solution using [`tshy`](https://github.com/isaacs/tshy). The core is now ESM, implemented as a module, and projects using `tshy` to CommonJS and ESM. The ESM build targets we will target include: - ESM (Node) - Browser - React-Native - Bun - Deno This will allow each system to pick up the correct output instead of picking the browser bundle which has happened in the past. Currently, our bun and deno support is strictly through npm compatibility and we are not forking logic at this point for those runtimes. In order to support ESM, `sinon` does not allow for ESM module mocking, so we looked for an alterative in `vitest`. This PR also migrates all core packages stated above from Mocha/Chai for Node and Mocha/Chai/Karma for the browser to using `vitest` for all tests. Currently, the system builds a test bundle which targets the correct files such as those targeted for the browser, eg `log-browser.mts` becomes `log.js` in the compiled output. ### What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen? ### Are there test cases added in this PR? _(If not, why?)_ ### Provide a list of related PRs _(if any)_ ### Command used to generate this PR:**_(Applicable only to SDK release request PRs)_ ### Checklists - [ ] Added impacted package name to the issue description - [ ] Does this PR needs any fixes in the SDK Generator?** _(If so, create an Issue in the [Autorest/typescript](https://github.com/Azure/autorest.typescript) repository and link it here)_ - [ ] Added a changelog (if necessary) --------- Co-authored-by: Deyaaeldeen Almahallawi <dealmaha@microsoft.com> Co-authored-by: Maor Leger <maorleger@users.noreply.github.com> Co-authored-by: Jeremy Meng <jeremy.ymeng@gmail.com>
2024-02-20 20:42:23 +03:00
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT License.
[core] Upgrade to ES-Modules for core (#26238) ### Packages impacted by this PR - @azure/abort-controller - @azure/core-auth - @azure/core-client - @azure-rest/core-client - @azure/core-http-compat - @azure/core-lro - @azure/core-paging - @azure/core-rest-pipeline - @azure/core-sse - @azure/core-tracing - @azure/core-util - @azure/core-xml - @azure/logger - @typespec/ts-http-runtime ### Issues associated with this PR ### Describe the problem that is addressed by this PR This migrates the core packages from a hybrid of CJS and ESM to an ESM solution using [`tshy`](https://github.com/isaacs/tshy). The core is now ESM, implemented as a module, and projects using `tshy` to CommonJS and ESM. The ESM build targets we will target include: - ESM (Node) - Browser - React-Native - Bun - Deno This will allow each system to pick up the correct output instead of picking the browser bundle which has happened in the past. Currently, our bun and deno support is strictly through npm compatibility and we are not forking logic at this point for those runtimes. In order to support ESM, `sinon` does not allow for ESM module mocking, so we looked for an alterative in `vitest`. This PR also migrates all core packages stated above from Mocha/Chai for Node and Mocha/Chai/Karma for the browser to using `vitest` for all tests. Currently, the system builds a test bundle which targets the correct files such as those targeted for the browser, eg `log-browser.mts` becomes `log.js` in the compiled output. ### What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen? ### Are there test cases added in this PR? _(If not, why?)_ ### Provide a list of related PRs _(if any)_ ### Command used to generate this PR:**_(Applicable only to SDK release request PRs)_ ### Checklists - [ ] Added impacted package name to the issue description - [ ] Does this PR needs any fixes in the SDK Generator?** _(If so, create an Issue in the [Autorest/typescript](https://github.com/Azure/autorest.typescript) repository and link it here)_ - [ ] Added a changelog (if necessary) --------- Co-authored-by: Deyaaeldeen Almahallawi <dealmaha@microsoft.com> Co-authored-by: Maor Leger <maorleger@users.noreply.github.com> Co-authored-by: Jeremy Meng <jeremy.ymeng@gmail.com>
2024-02-20 20:42:23 +03:00
import { defineConfig, mergeConfig } from "vitest/config";
import viteConfig from "../../../vitest.browser.base.config.ts";
[core] Upgrade to ES-Modules for core (#26238) ### Packages impacted by this PR - @azure/abort-controller - @azure/core-auth - @azure/core-client - @azure-rest/core-client - @azure/core-http-compat - @azure/core-lro - @azure/core-paging - @azure/core-rest-pipeline - @azure/core-sse - @azure/core-tracing - @azure/core-util - @azure/core-xml - @azure/logger - @typespec/ts-http-runtime ### Issues associated with this PR ### Describe the problem that is addressed by this PR This migrates the core packages from a hybrid of CJS and ESM to an ESM solution using [`tshy`](https://github.com/isaacs/tshy). The core is now ESM, implemented as a module, and projects using `tshy` to CommonJS and ESM. The ESM build targets we will target include: - ESM (Node) - Browser - React-Native - Bun - Deno This will allow each system to pick up the correct output instead of picking the browser bundle which has happened in the past. Currently, our bun and deno support is strictly through npm compatibility and we are not forking logic at this point for those runtimes. In order to support ESM, `sinon` does not allow for ESM module mocking, so we looked for an alterative in `vitest`. This PR also migrates all core packages stated above from Mocha/Chai for Node and Mocha/Chai/Karma for the browser to using `vitest` for all tests. Currently, the system builds a test bundle which targets the correct files such as those targeted for the browser, eg `log-browser.mts` becomes `log.js` in the compiled output. ### What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen? ### Are there test cases added in this PR? _(If not, why?)_ ### Provide a list of related PRs _(if any)_ ### Command used to generate this PR:**_(Applicable only to SDK release request PRs)_ ### Checklists - [ ] Added impacted package name to the issue description - [ ] Does this PR needs any fixes in the SDK Generator?** _(If so, create an Issue in the [Autorest/typescript](https://github.com/Azure/autorest.typescript) repository and link it here)_ - [ ] Added a changelog (if necessary) --------- Co-authored-by: Deyaaeldeen Almahallawi <dealmaha@microsoft.com> Co-authored-by: Maor Leger <maorleger@users.noreply.github.com> Co-authored-by: Jeremy Meng <jeremy.ymeng@gmail.com>
2024-02-20 20:42:23 +03:00
export default mergeConfig(
viteConfig,
defineConfig({
test: {
include: ["dist-test/browser/test/**/*.spec.js"],
},
}),
);