-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
commonjs wildcard imports only expose enumerable properties of requirees' exports #1778
Comments
On closer inspection, I'm not so convinced that this is really a bug that makes sense for I think it's pretty reasonable for For anyone else encountering a similar looking error, the workaround you're probably looking for is:
{
"module": {
"noInterop": true
}
} |
#### Details Profiling our unit tests showed that the overwhelming majority of time spent was in `ts-jest` parsing typescript files. This PR is an experiment in replacing `ts-jest` with an alternative typescript transpiler, `swc`, which is less mature but much faster. ##### Motivation On my local machine (a Surface Laptop 3 running Windows 21H1 OS Build 19043.985), comparative timings are: | scenario | `main` (ts-jest) | this PR (swc) | | - | - | - | | `yarn test -- -- --coverage=false -- footer-section.test.tsx` | 12s ±1s | 4.3s ±0.2s | | `yarn test -- -- -- footer-section.test.tsx` | 45s ±3s | 6.2s ±0.0s | | `yarn test` | 11m54s | 3m ±14s | On our CI build agents: | scenario | `main` (ts-jest) | this PR (swc) | | - | - | - | | unit tests | [15m1s](https://dev.azure.com/accessibility-insights/accessibility-insights-web/_build/results?buildId=21734&view=logs&j=3613c2bd-8b62-5a70-8491-3e8459586450&t=d1343856-9cd9-5649-cdc6-81bc16053e6f) | [5m9s](https://dev.azure.com/accessibility-insights/accessibility-insights-web/_build/results?buildId=21738&view=logs&j=3613c2bd-8b62-5a70-8491-3e8459586450&t=d1343856-9cd9-5649-cdc6-81bc16053e6f) | | web-e2e tests | [10m10s](https://dev.azure.com/accessibility-insights/accessibility-insights-web/_build/results?buildId=21734&view=logs&j=952ed597-794a-5756-0328-a93bb2daa2a4&t=46864a42-71df-5c2d-c60f-5fec8d56499d) | [8m6s](https://dev.azure.com/accessibility-insights/accessibility-insights-web/_build/results?buildId=21738&view=logs&j=952ed597-794a-5756-0328-a93bb2daa2a4&t=46864a42-71df-5c2d-c60f-5fec8d56499d) | | unified-e2e tests | [10m39s](https://dev.azure.com/accessibility-insights/accessibility-insights-web/_build/results?buildId=21734&view=logs&j=c5567cdb-c930-534d-6489-7c2dcf7ac8ee&t=fe6db478-348c-54d0-bafe-001288e28283) | [10m33s](https://dev.azure.com/accessibility-insights/accessibility-insights-web/_build/results?buildId=21738&view=logs&j=c5567cdb-c930-534d-6489-7c2dcf7ac8ee&t=fe6db478-348c-54d0-bafe-001288e28283) | | total PR build time | [~22m](https://dev.azure.com/accessibility-insights/accessibility-insights-web/_build?definitionId=38&_a=summary) | [~14m](https://dev.azure.com/accessibility-insights/accessibility-insights-web/_build/results?buildId=21740&view=results) | ##### Context This is not as clear cut a transition as the timings above suggest. `swc` is a relatively young project; it's not quite as firmly single-maintainer as `esbuild`, but it's still got a fairly concerning bus factor compared to `tsc` or `babel` (what `ts-jest` hands off to). Still, the timings speak for themselves and it's easy enough to transition back if that ever becomes necessary. If this experiment goes well, we might consider a similar change to update our webpack config to use `swc-loader` instead of `ts-loader`. One of the reasons `swc` is so much faster is that it does not perform type-checking. Right now we do type-checking as part of build, but if we were to switch webpack to use swc, we'd then need a separate build step for type-checking (comparable to the current `yarn null:check` step). Implementation notes: * There are a few subtly important things in the `.swcrc` file, which unfortunately doesn't support comments: * The `noInterop: true` flag is the equivalent of TypeScript's default `esModuleInterop: false` behavior. It is necessary; we use several modules which cannot be used correctly with interop behavior in play. See swc-project/swc#1778 for details. * The empty `"env": {}` property is necessary to trigger `swc` to respect the `browserslist` entry in `package.json` * Directing `swc` to target a reasonably recent set of browsers (via the new `browserslist` entry in `package.json`) is required; there are several tests with snapshots that change under default targeting, and there are a few components that break outright. * `tsx: true` is required (it tells `swc` to enable support for `tsx` files; it doesn't prevent non-tsx files from parsing) * For now, this is using a custom Jest transformer to call `@swc/core`. The swc project maintains a `@swc/jest` transformer, but swc-project/jest#8 prevents it from being able to use the `noInterop: true` setting we require, and I can't submit a PR to patch the project until legal rubber stamps their CLA * `collapsible-script-provider.tsx` required a hacky workaround for swc-project/swc#1165 * even after applying the workaround, running jest with and without `--coverage=false` emitted javascript with different whitespace. `collapsible-script-provider.test.ts` needed to be updated to format the resulting js before snapshotting it. * `src/scanner/processor.ts` used a mutable global in a module to enable its tests to inject test data. This confused swc; I replaced it with a more typical ctor injection pattern. * `browser-adapter-factory.test.tsx` did a dance around an `import 'webextension-polyfill-ts';` statement to trick the module into thinking `window.chrome.runtime.id` is defined (it checks for this during import and refuses to load if it is not set). The dance we used is not compliant with how ES6 imports are defined to work (they are defined as hoisting import statements to the top of the file, ie, before we stub the window property). TypeScript has an outstanding PR/issue to stop supporting what we were previously doing (microsoft/TypeScript#39764) and swc intentionally doesn't support it (swc-project/swc#1686) (babel doesn't either), so I had to modify how our dance worked by moving it to a separate file and having it use a raw `require()` rather than an `import`. #### Pull request checklist <!-- If a checklist item is not applicable to this change, write "n/a" in the checkbox --> - [n/a] Addresses an existing issue: #0000 - [x] Ran `yarn fastpass` - [x] Added/updated relevant unit test(s) (and ran `yarn test`) - [x] Verified code coverage for the changes made. Check coverage report at: `<rootDir>/test-results/unit/coverage` - [x] PR title *AND* final merge commit title both start with a semantic tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See `CONTRIBUTING.md`. - [n/a] (UI changes only) Added screenshots/GIFs to description above - [n/a] (UI changes only) Verified usability with NVDA/JAWS
This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
Describe the bug
_interopRequireWildcard
's implementation works by using afor(var key in obj)
loop over the required module's export to build up a new object with the same keys. This strategy does not cooperate with modules whose exports expose other types of capabilities. For example, it does not support commonjs modules whose exports are:Proxy
objects which supportget
operations of dynamic, non-enumerable properties (eg,identity-obj-proxy
)enzyme-adapter-react-16
)The specific motivating module in our case is identity-obj-proxy, which the Jest docs suggest as the recommended way to mock CSS modules. Its implementation is essentially:
We found this issue while experimenting with migrating an existing React codebase (microsoft/accessibility-insights-web) from
ts-jest
to@swc/jest
. Our project usesidentity-obj-proxy
per the Jest docs' suggestion of how to mock CSS modules, like this:With
ts-jest
, this strategy results in the component seeingstyles.myCoolButton
as"myCoolButton"
; with@swc/jest
, this results in the component seeingstyles.myCoolButton
asundefined
, because_interopRequireWildcard
' doesn't know to add amyCoolButton
property to the synthetic export it creates.The second motivating case we ran into was with the
enzyme-adapter-react-16
module, which exports a class and expects you to construct an instance of it. The synthetic export from_interopRequireWildcard
does not support having new instances constructed from it.Input code
repro-proxy-export.ts
:repro-class-export.ts
:.swcrc
:Config
With
@swc/jest
, default configuration (no.swcrc
file) repros. For standalone repro:Expected behavior
The two repros from the "Input code" section above should respectively:
identityObjProxy.testVar: testVar
Version
1.2.59
0.1.2
Additional context
n/a
The text was updated successfully, but these errors were encountered: