SalesforceCommerceCloud / pwa-kit

React-based JavaScript frontend framework to create a progressive web app (PWA) storefront for Salesforce B2C Commerce.
https://developer.salesforce.com/docs/commerce/pwa-kit-managed-runtime/guide/pwa-kit-overview.html
BSD 3-Clause "New" or "Revised" License
283 stars 130 forks source link

@W-16386042@ - Review Open Snyk PRs #1951

Closed shethj closed 1 month ago

shethj commented 2 months ago

This PR address some dependency upgrades in the monorepo as suggested by Snyk

Description

Non-Breaking Changes

The following dependencies have been bumped: dependencies old version new version packages
ws 8.13.0 8.18.0 pwa-kit-dev
njwt 1.2.0 2.1.0 template-retail-react-app
@aws-sdk/client-s3 3.450.0 3.622.0 template-mrt-reference-app

Breaking Changes

The following dependencies have been skipped:

dependencies old version new version packages
jest 26.6.3 29.7.0 internal-lib-build pwa-kit-dev
jest-cli 26.6.2 29.7.0 internal-lib-build pwa-kit-dev
jest-environment-jsdom 26.6.2 29.7.0 internal-lib-build pwa-kit-dev
babel-jest 26.6.3 29.7.0 internal-lib-build pwa-kit-dev
jest-environment-jsdom-global 2.0.4 4.0.0 internal-lib-build pwa-kit-dev

What breaks ?

This causes our test here to fail with error: ReferenceError: setImmediate is not defined

Possibel fixes:

Types of Changes

Breaking changes include:

  • Removing a public function or component or prop
  • Adding a required argument to a function
  • Changing the data type of a function parameter or return value
  • Adding a new peer dependency to package.json

Changes

How to Test-Drive This PR

Checklists

General

Accessibility Compliance

You must check off all items in one of the follow two lists:

or...

Localization

bfeister commented 2 months ago

Copying the discussion with @shethj for future reference for anyone who looks over this PR:

====

Brian Feister 11:39 AM Ok, so for the jest-environment-jsdom that gets used in our global jest.config.js in internal-lib-build/configs/jest/jest.config.js Soooooo, this means it technically wraps the configuration for ALL of our testing right? What happens when you don't use the polyfill?

Jainam Sheth :spiral_calendar_pad: 11:40 AM What happens when you don’t use the polyfill? This causes our test here to fail with error: ReferenceError: setImmediate is not defined express.test.js test('serveStaticFile returns 404 if the file does not exist', () => { const app = RemoteServerFactory._createApp(opts())

    app.get('/thing', RemoteServerFactory.serveStaticFile('this-does-not-exist.ico'))

setImmedeate is a node thing not a jest thing. It is used internally for scheduling test execution.

So you either use a polyfill for setImmedeate or you switch your jestEnvironment to node or you stay at v26.x

https://salesforce-internal.slack.com/archives/C07FNSQMKD3/p1722966072917589 switching environments will break more stuff

Brian Feister

Yeah I get that, but I think we want to know "how much stuff" we're breaking

I say that because our express / Node testing layer is thin so the impact could be small and we might not be stuck on old deps

Jainam Sheth

Use Node: Testing Node.js modules, servers, or utilities. Testing code that doesn’t rely on browser APIs or the DOM. Achieving faster test execution speeds (typically). Use jsdom: Testing frontend code that manipulates the DOM. Testing code that relies on browser-specific APIs like window, document, fetch, etc. Simulating user interactions with the DOM. I think we need the env to be jsdom

Brian Feister

Interesting, so do all current / new-ish React projects use the polyfill then?

I've been reading lately about how Google and other companies are trying to get away from jsdom

It might be worth looking around to see if say Next.js for example, uses the polyfill for jsdom in their testing

Jainam Sheth

I saw this bug on prisma: https://github.com/prisma/prisma/issues/8558 There are mixed opinions. One interesting comment is: “The way I see it, the fact that Jest 26 supported setImmediate in jsdom was a mistake corrected in Jest 27.” (link)

8558 Jest 27 errors with ReferenceError: setImmediate is not defined

https://github.com/prisma/prisma|prisma/prismaprisma/prisma | Aug 3rd, 2021 | Added by https://salesforce-internal.slack.com/services/B01UMHCT5AQ Comment on #8558 Jest 27 errors with ReferenceError: setImmediate is not defined https://github.com/[prisma/prisma](https://github.com/prisma/prisma)|prisma/prismaprisma/prisma | Jan 20th, 2022 | Added by https://salesforce-internal.slack.com/services/B01UMHCT5AQ

Brian Feister

Yeah, wow lots of opinions

What is your gut feeling about it after studying the implications?

Is it as simple as doing this with the polyfill?

    //@ts-ignore
    window.setImmediate = window.setTimeout

The file we’re seeing failing test is express.test.js which tests server APIs and satisfies use cases for testEnv to be node outlined here:

Use Node:

Testing Node.js modules, servers, or utilities.
Testing code that doesn't rely on browser APIs or the DOM.
Achieving faster test execution speeds (typically).
Use jsdom:

Testing frontend code that manipulates the DOM.
Testing code that relies on browser-specific APIs like window, document, fetch, etc.
Simulating user interactions with the DOM.

How do you feel about switching testEnvironments to node just for that test file ?

However I read setImmedeate is only supported in IE10 and exists in Node for now This doesn't matter because this is only for our testing environment, it won't impact customers, right?

Jainam Sheth 12:01 PM Nope. Won’t impact customers (edited)

Brian Feister Yeah so not a factor then

Jainam Sheth So then polyfill or set per-file env or not upgrade at all lol?

Brian Feister

How do you feel about switching testEnvironments to node just for that test file ? It seems that since we're testing express.js node would be the more correct testing env, so yeah I like that idea

Jainam Sheth

Cool. I can check to see if that works.

Brian Feister

Sounds good. Sounds like a big research project. Well done. Let's ship it if we can get a working solution

bfeister commented 1 month ago

Discussed with @kevinxh who is already working on the jest@27 upgrade. We don't need to go to jest@29 to fix the security vulnerability, and the vulnerability does not expose customers, as it is in devDependencies so not deployed to customer websites.

Opening a new PR to address the njwt vulnerability by simply deleting it, as it's unused