[code-infra] Modify publish script to filter packages by brijeshb42 · Pull Request #1236 · mui/mui-public

brijeshb42 · 2026-03-23T11:33:39Z

being published. The flag is same as pnpm -F and does the same thing
internally to call pnpm with the flag to get the list of packages to
publish.

This change is done to allow use to do two phase publishing in core
where we want one workflow job to publish only internal packages and the
other job to exclude such packages.

Refactored the code related to transitive dependency resolution and moved
it to pnpm utils module.

Tested locally with dry-run.

Related to - mui/material-ui#47952

Janpot · 2026-03-23T12:41:10Z

Alternatively, what if we support the pnpm -F filter expressions in getWorkspacePackages as an option. Then place all public packages under ./packages/, and all internal packages under ./packages-internal/ and filter on those folders? It feels like a more sustainable approach than having to fiddle with inclusion/exclusion lists in both publish commands. You can just put all public ones under one folder and all internal ones in another folder, nice and clear what the boundaries are. We already started creating these folders, this would enforce it.

mui-bot · 2026-03-23T14:43:58Z

Bundle size report

Bundle	Parsed size	Gzip size
@base-ui/react	0B^(0.00%)	0B^(0.00%)
@mui/x-charts-pro	0B^(0.00%)	0B^(0.00%)

Details of bundle changes

Check out the code infra dashboard for more information about this PR.

Janpot · 2026-03-23T14:48:14Z

+        type: 'string',
+        array: true,
+        description:
+          'pnpm --filter expressions to select which packages to publish (same syntax as `pnpm -F`). When omitted, all public packages are published.',


Is that a union or intersection of the filter? How does it work in pnpm?

Separate filters mean packages that satisfy any of the patterns. So union.

https://pnpm.io/filtering#multiplicity

Janpot · 2026-03-23T15:49:50Z

+      const publishNames = new Set(packagesToPublish.map((pkg) => pkg.name));
+      const depsOnly = await getWorkspacePackages({
+        publicOnly: true,
+        filter: filter.map((f) => `${f}^...`),


I was thinking, we should probably widen this check. e.g. packages should not depend on workspace: packages that are not in the list returned from getWorkspacePackages, also when no filter is specified. e.g. what if it has a workspace dependency on a private package. I also don't think this trick would work correctly if the filter is something like foo-*.

I think we could probable generalize and reuse getTransitiveDependencies on all the packages, then check if it returned any package not in the list.

Since the check is reused in multiple places, perhaps we should create a function for it as well:

function getExtraneousWorkspaceDependency(packageList: string[]): string[]

or something, which returns a list of workspace packages that anything in packageList transitively depends on without including it.

Janpot · 2026-03-24T17:12:15Z


+/**
+ * @typedef {Object} GetTransitiveDependenciesOptions
+ * @property {boolean} [includeDev=true] - Whether to include devDependencies in the traversal


should we also add includeProd then?

Janpot · 2026-03-24T17:13:08Z

+ * roots depend on it.
+ *
+ * @param {string[]} packageNames - Package names to start the traversal from
+ * @param {Map<string, string>} workspacePathByName - Map of workspace package name to directory path


Should this go in the options?

I could go either way.

Janpot · 2026-03-24T17:15:27Z

+ * @param {GetTransitiveDependenciesOptions} [options]
+ * @returns {Promise<Set<string>>} All reachable workspace package names, including the input packages themselves
+ */
+export async function getTransitiveDependencies(packageNames, workspacePathByName, options = {}) {


workspacePathByName feels very leaky. One thing we could do is create a function that fetches this, but caches the results. Maybe something for follow-up

Janpot · 2026-03-24T17:17:07Z

+ *   Sets of package names that violate the requirements. Both sets are empty when valid.
+ */
+export async function validatePublishDependencies(packages) {
+  const allWorkspacePackages = await getWorkspacePackages();


Calling getWorkspacePackages again while it was already called to obtain packages is a bit wasteful. I'm not sure how we can fix this though without creating leaky abstractions. Perhaps some of the commands need to cache their results? We can do it in follow-up

Yeah. This here is being done to get all public and private packages so we can track if something is not included in the publish list.
I think its fine though since the script code-infra publish or code-infra publish-canary is only called once in a release trigger. Can be looked into it separately.

Janpot

Approving, but from a maintainability POV, would prefer to keep validation logic internal to validatePublishDependencies

This also includes a refactoring of existing transitive dependency checker in cmdNetlifyIgnore. It handles checking if the filtered publishable packages have any dependency that is not published or is private.

brijeshb42 requested a review from a team March 23, 2026 11:33

brijeshb42 added the scope: code-infra Involves the code-infra product (https://www.notion.so/mui-org/5562c14178aa42af97bc1fa5114000cd). label Mar 23, 2026

brijeshb42 changed the title ~~[code-infra] Modify publish script to exclude packages~~ [code-infra] Modify publish script to filter packages Mar 23, 2026

brijeshb42 force-pushed the publish-exclude branch from 929d3e2 to c0a1edf Compare March 23, 2026 14:45

Janpot reviewed Mar 23, 2026

View reviewed changes

brijeshb42 force-pushed the publish-exclude branch from c0a1edf to 32dff0b Compare March 23, 2026 15:15

brijeshb42 requested a review from Janpot March 23, 2026 15:17

Janpot reviewed Mar 23, 2026

View reviewed changes

brijeshb42 force-pushed the publish-exclude branch 4 times, most recently from a4aa4c0 to 64fbd90 Compare March 24, 2026 16:29

brijeshb42 requested review from a team and Janpot March 24, 2026 16:32

Janpot reviewed Mar 24, 2026

View reviewed changes

brijeshb42 force-pushed the publish-exclude branch from 64fbd90 to 70ed950 Compare March 25, 2026 06:34

brijeshb42 requested a review from Janpot March 25, 2026 15:31

Janpot approved these changes Mar 25, 2026

View reviewed changes

Comment thread packages/code-infra/src/cli/cmdPublish.mjs Outdated

brijeshb42 added 2 commits March 26, 2026 13:11

[code-infra] Add --filter arg to publish and list commands

e9c1116

This also includes a refactoring of existing transitive dependency checker in cmdNetlifyIgnore. It handles checking if the filtered publishable packages have any dependency that is not published or is private.

Restructure the error thrown

0bf94b3

brijeshb42 force-pushed the publish-exclude branch from 70ed950 to 0bf94b3 Compare March 26, 2026 07:52

brijeshb42 enabled auto-merge (squash) March 26, 2026 07:52

brijeshb42 merged commit b989d00 into master Mar 26, 2026
11 of 12 checks passed

brijeshb42 deleted the publish-exclude branch March 26, 2026 07:53

Conversation

brijeshb42 commented Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Janpot commented Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mui-bot commented Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Bundle size report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

brijeshb42 Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Janpot Mar 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Janpot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

brijeshb42 commented Mar 23, 2026 •

edited

Loading

Janpot commented Mar 23, 2026 •

edited

Loading

mui-bot commented Mar 23, 2026 •

edited

Loading

brijeshb42 Mar 23, 2026 •

edited

Loading

Janpot Mar 24, 2026 •

edited

Loading