[DEPR]: karma-selenium-webdriver-launcher

[brian-smith-tcril]

RFC Start Date

2023-03-26

Target Plan Accepted Date

2023-04-09

Target Transition Unblocked Date

2023-04-09

Earliest Breaking Changes Unblocked Date

2023-04-09

Earliest Open edX Named Release Without This Functionality

Ulmo - 2025-06

Rationale

In the process of upgrading edx-platform to node 18, npm install failed because the selenium-webdriver peer dependency in karma-selenium-webdriver-launcher is set to ^2.44.0, but we have 3.4.0 as a dev dependency.

To work around this issue, we forked karma-selenium-webdriver-launcher to the openedx GH org, and updated the peer dependency to allow newer versions of selenium-webdriver (https://github.com/openedx/karma-selenium-webdriver-launcher/pull/1/files)

This package is unmaintained (hasn't been updated in 8 years), and there are other ways to handle this problem.

Removal

• The https://github.com/openedx/karma-selenium-webdriver-launcher repo
• All usage of karma-selenium-webdriver-launcher in edx-platform and any other repos using it

Replacement

TBD

Deprecation

No response

Migration

No response

Additional Info

No response

Task List

No response

[tonybusa]

assign me

[tonybusa]

I've started on this ticket. It appears the only references for the package are within edx-platform (other than the library itself):
https://github.com/search?q=org%3Aopenedx+karma-selenium-webdriver-launcher&type=code

After removing the references, I'm able to build and run the platform. But I assume we rely on this package for running tests? I'll continue my research within this article: https://docs.openedx.org/projects/edx-platform/en/latest/concepts/testing/testing.html#running-javascript-unit-tests

The ticket mentions "there are other ways to handle this problem". @brian-smith-tcril if you have insight on this please let me know. Since the replacement says "TBD" I'll continue to tackle the testing problem, if that's is the correct verification of this ticket being "done", and will report back any findings in another comment. Thanks!

[tonybusa]

I was able to get the karma tests running locally from edx-platform with the following commands (I use Chrome as my browser):

karma start  cms/static/karma_cms.conf.js --browsers=Chrome --single-run=false

and

 karma start lms/static/karma_lms.conf.js --browsers=Chrome --single-run=false 

The LMS command fails unless I comment out the following spec files that are using Webpack:

from file: lms/static/karma_lms.conf.js

  // Define the Webpack-built spec files first
   {pattern: 'course_experience/js/**/*_spec.js', webpack: true},
   {pattern: 'js/learner_dashboard/**/*_spec.js', webpack: true},
   {pattern: 'js/student_account/components/**/*_spec.js', webpack: true},
   {pattern: 'completion/js/**/*_spec.js', webpack: true},

Also mentioning that this file can be removed from the sourceFiles array in the same config file since it doesn't reference any tests:

{ pattern: "learner_profile/**/!(*spec).js" },

I suspect that may be the basis of this issue, since the test-karma-webpack command gets ignored in the CI anyways. Perhaps these are unrelated but figured I'd mention it.

Noting the results from the LMS run: 781 specs, 8 failures, 6 pending specs
Failures:

1. discovery.views.CourseCard renders
   2-8)

[tonybusa]

Posting the link the PR I created and some notes from @brian-smith-tcril.

openedx/edx-platform#36589

Brian indicated that https://github.com/openedx/edx-platform/blob/2eb0adb4402b4ca30a6444a0a9c1b15646924923/package.json#L27 as in test-lms doesn't get run in the CI. I'm curious if we want coverage on the karma tests that don't require webpack as noted in the comment above. However, there would need to be fixes implemented for the 8 tests failing above. Waiting to see how my PR does in the CI before following up in the working group next week!

[robrap]

[inform] This DEPR is in the Draft state. It can't move forward without a DEPR coordinator to help update it to match the updated DEPR template. No action is required, unless anyone wants to move this out of Draft.

[e0d]

Hi @robrap I think we need to prioritize getting issues that are older and have effort put into them over the line. What's the best way to do that? I'm happy to steward this issue in the case, but I want to make sure we're not creating a pile of issues that need similar interventions when we'd all be better off getting them to done.

[robrap]

@e0d: Getting a DEPR WG coordinator assigned to the ticket is the best way, and @kdmccormick and @feanil have been seeing through most of the axim-initatied tickets. Maybe one of them can coordinate and get this ticket into the right place. The updated process doesn't really add new work, but just makes the transitions and operator impact more clear. Thanks!

[robrap]

Also, @e0d, just so you are clear - the interventions are minor - and will just help 2U and MIT be clear how and when we will be impacted, and how to prepare properly. There are way too many tickets in an unclear state to know at this point. If this ticket moves along, at least it will be on our radar.