Skip to content

feat: modernize Problem Block JS, enable Babel on capa files#38718

Open
irfanuddinahmad wants to merge 4 commits into
masterfrom
irfanuddinahmad/modernize-problem-block-js-438
Open

feat: modernize Problem Block JS, enable Babel on capa files#38718
irfanuddinahmad wants to merge 4 commits into
masterfrom
irfanuddinahmad/modernize-problem-block-js-438

Conversation

@irfanuddinahmad

@irfanuddinahmad irfanuddinahmad commented Jun 5, 2026

Copy link
Copy Markdown
Contributor

Summary

Closes openedx/public-engineering#438

This PR modernizes the Problem Block JavaScript build pipeline by:

  • Removing the overly-broad /xmodule\/js\/src/ regex from the string-replace-loader exclusion and babel-loader exclusion lists in both webpack-config/file-lists.js and webpack.common.config.js. Only the 3 files that actually contain RequireJS patterns are now listed explicitly: poll/poll.js, poll/poll_main.js, video/08_video_auto_advance_control.js.
  • Enabling Babel processing on all capa files (display.js, imageinput.js, schematic.js) — previously they were excluded from Babel by the broad regex despite having no RequireJS patterns.
  • Fixing an implicit global in schematic.js (schematic = (function()... → var schematic = (function()...) which would throw a ReferenceError under Babel's strict mode.
  • Migrating capa Karma tests from the legacy karma_xmodule.conf.js runner to the modern webpack-based karma_runner_webpack.js, and excluding them from the legacy runner.

Test plan

  • npm run build-dev passes with no build errors
  • npm run test-xmodule-webpack — capa tests (display_spec.js, imageinput_spec.js) pass in the webpack runner
  • npm run test-xmodule-vanilla — remaining legacy xmodule tests (non-video, non-capa) still pass

🤖 Generated with Claude Code

@openedx-webhooks openedx-webhooks added open-source-contribution PR author is not from Axim or 2U core contributor PR author is a Core Contributor (who may or may not have write access to this repo). labels Jun 5, 2026
@openedx-webhooks

openedx-webhooks commented Jun 5, 2026

Copy link
Copy Markdown

Thanks for the pull request, @irfanuddinahmad!

This repository is currently maintained by @openedx/wg-maintenance-openedx-platform.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

  • If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
    • This process (including the steps you'll need to take) is documented here.
  • If it doesn't, simply proceed with the next step.
🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

  • Dependencies

    This PR must be merged before / after / at the same time as ...

  • Blockers

    This PR is waiting for OEP-1234 to be accepted.

  • Timeline information

    This PR must be merged by XX date because ...

  • Partner information

    This is for a course on edx.org.

  • Supporting documentation
  • Relevant Open edX discussion forum threads
🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

Details
Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

  • The size and impact of the changes that it introduces
  • The need for product review
  • Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

@github-project-automation github-project-automation Bot moved this to Needs Triage in Contributions Jun 5, 2026
@mphilbrick211 mphilbrick211 moved this from Needs Triage to Ready for Review in Contributions Jun 5, 2026
Irfan Ahmad and others added 4 commits June 11, 2026 12:58
@claude
feat: modernize Problem Block JS, enable Babel on capa files
0b47225 
Removes the broad /xmodule\/js\/src/ regex from the string-replace-loader
and babel-loader exclusion lists, replacing it with explicit paths for only
the three files that actually contain RequireJS patterns (poll.js,
poll_main.js, 08_video_auto_advance_control.js). This allows Babel to
process the capa files (display.js, imageinput.js, schematic.js).

Also fixes an implicit global variable in schematic.js that would throw
under Babel strict mode, and migrates capa Karma tests from the legacy
runner to the webpack-based runner.

Closes openedx/public-engineering#438

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@claude
fix: set window.imagediff for jasmine-extensions matcher registration
dacfa23 
jasmine-extensions.js registers toImageDiffEqual only if window.imagediff
is set. When imported via webpack, jasmine-imagediff.js uses the CommonJS
path (module.exports) and never sets window.imagediff. Import it as a
named default and assign to window explicitly so the matcher is available
for display_spec.js imageinput tests.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@claude
fix: move window.imagediff assignment after all imports
8027731 
ES module imports are hoisted, so the assignment must live after all
imports (alongside other window.* globals). This is safe because
jasmine-extensions.js registers the addMatchers call inside a beforeEach
callback, so window.imagediff only needs to be set before tests run,
not at module load time.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@claude
docs: add comments explaining explicit RequireJS file lists
7b3214a 
Clarifies why the three xmodule/js/src/ files are listed explicitly and
signals to future contributors that new files should use ES6+ and must
not be added here.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@irfanuddinahmad irfanuddinahmad force-pushed the irfanuddinahmad/modernize-problem-block-js-438 branch from 6adfd7a to 7b3214a Compare June 11, 2026 07:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@farhan farhan Awaiting requested review from farhan farhan is a code owner

@irtazaakram irtazaakram Awaiting requested review from irtazaakram irtazaakram is a code owner

@salman2013 salman2013 Awaiting requested review from salman2013 salman2013 is a code owner

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

core contributor PR author is a Core Contributor (who may or may not have write access to this repo). open-source-contribution PR author is not from Axim or 2U

Projects

Contributions
Status: Ready for Review

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Modernize Problem Block JavaScript

3 participants

@irfanuddinahmad @openedx-webhooks @mphilbrick211