Clean up pyproject.toml and build pipeline

[emilykl]

Link to issue

Closes #5537

Description of change

• Switch build backend from setuptools to hatch
  • hatch is distributed by PyPA and has a number of advantages compared to setuptools, including being newer and more modern
• Update pyproject.toml config to work with hatch, and remove unused config sections
  • Remove MANIFEST.in file, since it's only required by setuptools, not needed for hatch
• Update js/package.json to reflect the correct version number matching plotly.py version, which we've forgotten to do for the last few releases
  • Add CI step to check that version numbers match
• Add js/webpack.config.js to make lab extension build output identical across platforms, which fixes the false failure of the "Check JS build" workflow
• Update RELEASE.md instructions to add step to update version number in js/package.json
• Remove keys from js/install.json file which I believe are not needed

NOTE: The build command remains the same: python -m build .

Demo

python-m-build.mov

When running python -m build . locally, the output should look like the above.

Testing strategy

I've added a CI step in .github/workflows/check-js-build.yml to check that the version number in pyproject.toml matches the version number in js/project.json, which should prevent the two from getting out of sync again.

Show success case

Show failure case

No additional unit testing is needed: The CI already runs `python -m build .` , so if that step fails then we know something is wrong.

However, we should verify manually that the resulting build is the same before and after these changes.

This can be done by checking out this branch, running python -m build ., and comparing the .tar.gz and .whl files to the official 6.6.0 release artifacts.

Additional information (optional)

Because we manually pre-build the assets for the JupyterLab extension (by running npm run build from the js/ directory, as documented in the CONTRIBUTING.md), we do not use any of the hatch build hooks settings in the pyproject.toml, so this PR removes them.

The existing .github/check-js-build.yml step builds the lab extension in CI and ensures that the output matches the build artifacts in plotly/labextension/.

I don't like that this setup requires updating the version number in two places. But package.json doesn't support dynamic version numbers, so the only way to set up a single source of truth would be for the package.json to be the single source of truth, and pyproject.toml to load that version number dynamically. I don't like that for a Python project. But open to suggestions.

Guidelines

• I have reviewed the pull request guidelines and the Code of Conduct and confirm that this PR follows them.
• I have added an entry to the changelog if needed (not required for documentation PRs).

[emilykl]

fyi @franred this is the PR I mentioned last week!

[Copilot]

Pull request overview

This PR modernizes plotly.py’s packaging/build configuration by switching the Python build backend to hatchling, cleaning up legacy pyproject.toml sections, and tightening the JupyterLab extension build/versioning workflow to reduce CI drift and cross-platform build artifact differences.

Changes:

• Switch Python build backend from setuptools to hatchling and remove legacy setuptools/jupyter-packaging config.
• Align JupyterLab extension versions and stabilize webpack output across platforms.
• Add CI checks to keep Python and JS version numbers in sync and improve the JS build artifact comparison workflow.

Reviewed changes

Copilot reviewed 10 out of 15 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
uv.lock	Updates dev/dev-build deps away from the jupyter meta-package toward explicit jupyterlab pins.
pyproject.toml	Switches to hatchling and replaces packaging data/sharing configuration for the labextension.
plotly/labextension/static/remoteEntry.*.js	Updates committed prebuilt labextension artifacts (hash/version changes).
plotly/labextension/static/*.LICENSE.txt	Adds/updates bundled license output from the JS build.
plotly/labextension/package.json	Updates extension version and build metadata (including webpack config and new remoteEntry filename).
js/webpack.config.js	Forces stable webpack IDs/content hashing for cross-platform deterministic outputs.
js/package.json	Updates JS package version and points JupyterLab builder at the custom webpack config.
js/package-lock.json	Updates lockfile; currently shows a version mismatch vs js/package.json.
js/install.json	Simplifies install metadata intended for JupyterLab extension installation UX.
RELEASE.md	Adds release step to update js/package.json version.
MANIFEST.in	Removed as part of moving away from setuptools.
.github/workflows/check-js-build.yml	Adds version-sync check and tweaks the artifact-compare workflow; still uses deprecated setup-node@v2.

Files not reviewed (1)

• js/package-lock.json: Language not supported

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[camdecoster]

Does uv have something similar to npm version? If so, maybe they have post script hooks, also like npm?

[emilykl]

Hatch itself has a whole system for build hooks which we could definitely make use of.

I started going down that path for compiling the JS artifacts (i.e., adding the npm run build step as a hook which would run every time the Python package was built) but the jupyter labextension build step is VERY slow (like 20-30 seconds) and it didn't seem easy to control whether it runs or not. Worth looking more into in the future though.