upgrade to 1.1.3 breaks certain tests

[satyasekharcvb]

Description

Upgrade to 1.1.3 breaks tests of the components that refer to the crypto class and that import CSS module. Screens shots attached

Steps to Reproduce

1. Checkout lwc recipes from https://github.com/trailheadapps/lwc-recipes
2. change "@salesforce/sfdx-lwc-jest" value to "^1.1.3" in package.json.
3. run - npm install
4. run - npm test

// simplified test case
import { createElement } from 'lwc';
import CompositionBasics from 'c/compositionBasics';

describe('c-composition-basics', () => {
    afterEach(() => {
        // The jsdom instance is shared across test cases in a single file so reset the DOM
        while (document.body.firstChild) {
            document.body.removeChild(document.body.firstChild);
        }
    });

    it('renders one contact tile', () => {
        // Create initial element
        const element = createElement('c-composition-basics', {
            is: CompositionBasics
        });
        document.body.appendChild(element);

        // Select rendered contact tile for length check
        const contactTileEls =
            element.shadowRoot.querySelectorAll('c-contact-tile');
        expect(contactTileEls.length).toBe(1);
    });
}

<!-- HTML for component under test -->
<template> ... </template>

// CSS for component under test
@import 'c/cssLibrary';

Expected Results

All tests in LWC Recipes should pass

Actual Results

Tests of the components that refer to the crypto class and that import CSS module fails - screens shots attached

Version

• @salesforce/sfdx-lwc-jest: 1.1.3
• Node: 14.19.3

Additional context/Screenshots Test results of the component using crypto.randomUUID()

Test results of the component that imports CSS module

[nolanlawson]

Thanks for reporting. We're looking into this. ^

[nolanlawson]

@satyasekharcvb For the second issue (the c/cssLibrary one), could you confirm that the same code works in a non-Jest environment? (I.e. a browser?)

From looking at the Trailhead code, it's not clear to me that c/cssLibrary is set up as a module resolution target in a lwc.config.json (or equivalent) anywhere. If this only happened to work in a Jest environment (and nowhere else), it could have been that https://github.com/salesforce/lwc-test/pull/160 was hiding a bug that only revealed itself once the CSS was actually being rendered. (Before that PR, CSS was ignored in LWC Jest tests.)

[pozil]

@nolanlawson some updates on the issue.

We got rid of the crypto bit as we didn't need it much.

However the CSS import issue is more problematic. This code has been part of our sample apps LWC Recipes for quite some time now and it works well as you can see in this screenshot:

[nolanlawson]

@satyasekharcvb @pozil I have good news and bad news.

The good news is that I can fix this particular issue with CSS imports: https://github.com/salesforce/lwc-test/pull/162

The bad news is that you may need to update your moduleNameMapper config to do the correct mapping to the cssLibrary.css file. E.g.:

  "^c/(.+)$": "<rootDir>/path/to/my/modules/$1/$2/$2"

The reason for this is that lwc-test implements its own resolution separate from the lwc.config.json used in the Rollup plugin (W-9989179).

[satyasekharcvb]

Thank you, @nolanlawson!!

[supert3d1975]

Just ran into this issue myself today. Is there a better way of doing this yet, other than the workaround of adding (example):

"^c/(.+)$": "<rootDir>/path/to/my/modules/$1/$2/$2"

To the moduleNameMapper for the resolver?

I think there was some updates Aug, 2023. But anymore updates to remove the necessity to do this?

[nolanlawson]

@supert3d1975 Sorry no, this is still the recommended solution.