Should @edx/mockprock continue to be published to npm?

[farhan]

Important

Issue created with the assistance of Claude Code. Manually reviewed before being submitted.

Background

As part of making mockprock PyPI-publishable (PR #68), the existing release.yml was renamed to npm-release.yml and a new pypi-release.yml was added alongside it. The npm workflow file is still present and unchanged — but it fails on every run at the npm run build step because package.json has no "build" script. It never reaches npx semantic-release@25. This issue tracks the open question of whether npm publishing should be restored, kept dead, or formally dropped.

History of npm publishing

December 2018 — Only time npm was ever published

Matt Hughes manually pushed npmv* tags to trigger Travis CI, which had deploy: provider: npm with condition: $TRAVIS_TAG =~ ^npmv.*$. This published three versions to the npm registry:

• 1.0.0 — 2018-12-06 — bf839f8
• 1.0.1 — 2018-12-06 — c9e4814
• 1.0.2 — 2018-12-20 — af4e06a

The npm registry confirms this: "_npmUser": "edx-semantic-release", "_npmVersion": "2.15.1" — matching Travis CI's environment. GitHub Actions did not exist in December 2018.

2021 — GitHub Actions added, npm publishing already dead

PR #25 migrated from Travis to GitHub Actions. The author noted: "There was no CI check present in Travis. Only npm release workflow was present so replicated that in GitHub CI." The workflow used cycjimmy/semantic-release-action@v2 with NPM_TOKEN — but no npmv* tags were ever pushed again, so it never ran.

January 2026 — npm token intentionally removed

PR #62 removed NPM_TOKEN and switched to GITHUB_TOKEN only, following the pattern from openedx/frontend-platform#847. This appears to have been an intentional decision to stop npm publishing.

July 2026 — Current state (PR #68)

PR #68 renames release.yml → npm-release.yml and adds a new pypi-release.yml with python-semantic-release + OIDC PyPI publishing. The npm workflow file is not removed — it runs unchanged on every push to master. The workflow has been failing on every run since at least PR #62 — npm run build errors with "Missing script: build" because package.json has no build script, so npx semantic-release@25 is never even reached (example failing run). The npm side is effectively broken, not formally dropped.

Why it matters

mockprock/backend.py declares:

npm_module = '@edx/mockprock'

And edx-proctoring/edx_proctoring/apps.py reads this field to locate the frontend bundle on disk:

package_file = os.path.join(settings.NODE_MODULES_ROOT, package, 'package.json')

It does a local filesystem lookup — it does not install from npm at runtime. So the npm registry is not strictly required for the package to function. However, if any platform setup does npm install @edx/mockprock, it gets the 2018 code (v1.0.2).

The question

Should we:

Option A — Keep npm publishing, drop semantic-release from the npm workflow
Strip npx semantic-release@25 from npm-release.yml and replace it with a plain npm publish step. Version tagging stays owned by pypi-release.yml (python-semantic-release); npm-release.yml just builds and publishes the npm package on each release tag. Requires adding a "build" script to package.json and restoring NPM_TOKEN. Each workflow has a single responsibility and there is no conflict on release tagging.

Option B — Remove npm-release.yml entirely
Formally retire npm publishing by deleting npm-release.yml, package.json, .nvmrc, and the static frontend assets. Also remove npm_module = '@edx/mockprock' from backend.py if the frontend assets are no longer needed. This cleanly ends the npm chapter.

Recommendation

Option B unless there is a known consumer that does npm install @edx/mockprock today. The last publish was over 7 years ago, PR #62 already made the intentional call to drop the npm token, and the edx-proctoring filesystem lookup does not require the registry.

/cc @feanil @arbrandes

[arbrandes]

I don't even know what mockprock does. (Well, I do now, after reading the README.) I'll let @feanil or @kdmccormick tackle this one.

[feanil]

So it looks like the node module is used to load the provider JS which in the case of mockprock is just a single index.js file.

From my read of it, mockprock is both a JS bundle and a flask based server that serves as the mock backend for proctoring. Given this understanding, I think it makes sense to publish to both to NPM and to pypi. On the NPM side, we should publish to @openedx/mockprock.

[feanil]

So it looks like the node module is used to load the provider JS which in the case of mockprock is just a single index.js file.

From my read of it, mockprock is both a JS bundle and a flask based server that serves as the mock backend for proctoring. Given this understanding, I think it makes sense to publish to both to NPM and to pypi. On the NPM side, we should publish to @openedx/mockprock.

[feanil]

So it looks like the node module is used to load the provider JS which in the case of mockprock is just a single index.js file.

From my read of it, mockprock is both a JS bundle and a flask based server that serves as the mock backend for proctoring. Given this understanding, I think it makes sense to publish to both to NPM and to pypi. On the NPM side, we should publish to @openedx/mockprock.

[feanil]

So it looks like the node module is used to load the provider JS which in the case of mockprock is just a single index.js file.

From my read of it, mockprock is both a JS bundle and a flask based server that serves as the mock backend for proctoring. Given this understanding, I think it makes sense to publish to both to NPM and to pypi. On the NPM side, we should publish to @openedx/mockprock.

[feanil]

So it looks like the node module is used to load the provider JS which in the case of mockprock is just a single index.js file.

From my read of it, mockprock is both a JS bundle and a flask based server that serves as the mock backend for proctoring. Given this understanding, I think it makes sense to publish to both to NPM and to pypi. On the NPM side, we should publish to @openedx/mockprock.

[feanil]

So it looks like the node module is used to load the provider JS which in the case of mockprock is just a single index.js file.

From my read of it, mockprock is both a JS bundle and a flask based server that serves as the mock backend for proctoring. Given this understanding, I think it makes sense to publish to both to NPM and to pypi. On the NPM side, we should publish to @openedx/mockprock.

[feanil]

So it looks like the node module is used to load the provider JS which in the case of mockprock is just a single index.js file.

From my read of it, mockprock is both a JS bundle and a flask based server that serves as the mock backend for proctoring. Given this understanding, I think it makes sense to publish to both to NPM and to pypi. On the NPM side, we should publish to @openedx/mockprock.

[feanil]

So it looks like the node module is used to load the provider JS which in the case of mockprock is just a single index.js file.

From my read of it, mockprock is both a JS bundle and a flask based server that serves as the mock backend for proctoring. Given this understanding, I think it makes sense to publish to both to NPM and to pypi. On the NPM side, we should publish to @openedx/mockprock.

[feanil]

So it looks like the node module is used to load the provider JS which in the case of mockprock is just a single index.js file.

From my read of it, mockprock is both a JS bundle and a flask based server that serves as the mock backend for proctoring. Given this understanding, I think it makes sense to publish to both to NPM and to pypi. On the NPM side, we should publish to @openedx/mockprock.

[feanil]

So it looks like the node module is used to load the provider JS which in the case of mockprock is just a single index.js file.

From my read of it, mockprock is both a JS bundle and a flask based server that serves as the mock backend for proctoring. Given this understanding, I think it makes sense to publish to both to NPM and to pypi. On the NPM side, we should publish to @openedx/mockprock.

[feanil]

So it looks like the node module is used to load the provider JS which in the case of mockprock is just a single index.js file.

From my read of it, mockprock is both a JS bundle and a flask based server that serves as the mock backend for proctoring. Given this understanding, I think it makes sense to publish to both to NPM and to pypi. On the NPM side, we should publish to @openedx/mockprock.