files excludes src/index.scss but not src/index-with-dependencies.scss. Both are Storybook-only entry points, so this looks like the exclusion being one file short of its own intent rather than a deliberate choice.
Noticed while doing the @use swap in #2431. That PR needed a changeset it was not scheduled to have, because the file it changed turns out to ship.
It ships, and it is the only top-level Sass file that does
npm pack puts 361 files in the tarball. Confirmed by installing that tarball into a scratch project:
node_modules/@cloudfour/patterns/src/index-with-dependencies.scss <- present
node_modules/@cloudfour/patterns/src/index.scss <- correctly absent
It is the only src/*.scss at that level in the tarball.
Three independent reasons a consumer cannot use it
1. It imports a devDependency. Compiling it as a consumer fails outright:
Can't find stylesheet to import.
╷
19 │ @use '../node_modules/@wordpress/block-library/build-style/style';
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
╵
node_modules/@cloudfour/patterns/src/index-with-dependencies.scss 19:1 root stylesheet
../node_modules/ resolves inside our own package directory, and @wordpress/block-library is a devDependency. We declare no dependencies and no peerDependencies, so it is never installed for a consumer.
2. Past that, it loads a file we deliberately excluded. The next line is @use './index', and src/index.scss is excluded from files on purpose. So even with the block library available, the file cannot resolve its own sibling.
3. Its font paths are meaningless outside our Storybook. It configures base/fonts with $dir: '/src/assets/fonts', a root-absolute path chosen so Vite can find the files while serving Storybook. In a consumer's site that points at a directory on their domain.
Suggested fix
Mirror the existing exclusion:
"files": [
..."!src/index.scss",
"!src/index-with-dependencies.scss"
]
A patch, not a break: nothing that cannot compile can have a working consumer to break. files affects only the tarball, so Storybook — which reads the file from the working tree — is unaffected.
Worth deciding at the same time whether the file belongs in src/ at all, given it is Storybook configuration rather than library source. Moving it under .storybook/ would put it outside every files glob and make the Storybook-only comment at the top of it structurally true instead of a promise.
Relationship to #2078
Related but not the same, and not covered by it. #2078 is about files we intend to publish that exports makes unreachable — the fix there widens the public surface. This is a file we do not intend to publish that ships anyway, so the fix narrows it. It is the Sass-side counterpart of #2427, which was the same mistake in the JS bundle.
Both belong to the "what is actually our public surface" question #2078 and #2427 were already circling, so it may be worth answering all three together.
filesexcludessrc/index.scssbut notsrc/index-with-dependencies.scss. Both are Storybook-only entry points, so this looks like the exclusion being one file short of its own intent rather than a deliberate choice.Noticed while doing the
@useswap in #2431. That PR needed a changeset it was not scheduled to have, because the file it changed turns out to ship.It ships, and it is the only top-level Sass file that does
npm packputs 361 files in the tarball. Confirmed by installing that tarball into a scratch project:It is the only
src/*.scssat that level in the tarball.Three independent reasons a consumer cannot use it
1. It imports a devDependency. Compiling it as a consumer fails outright:
../node_modules/resolves inside our own package directory, and@wordpress/block-libraryis a devDependency. We declare nodependenciesand nopeerDependencies, so it is never installed for a consumer.2. Past that, it loads a file we deliberately excluded. The next line is
@use './index', andsrc/index.scssis excluded fromfileson purpose. So even with the block library available, the file cannot resolve its own sibling.3. Its font paths are meaningless outside our Storybook. It configures
base/fontswith$dir: '/src/assets/fonts', a root-absolute path chosen so Vite can find the files while serving Storybook. In a consumer's site that points at a directory on their domain.Suggested fix
Mirror the existing exclusion:
A patch, not a break: nothing that cannot compile can have a working consumer to break.
filesaffects only the tarball, so Storybook — which reads the file from the working tree — is unaffected.Worth deciding at the same time whether the file belongs in
src/at all, given it is Storybook configuration rather than library source. Moving it under.storybook/would put it outside everyfilesglob and make the Storybook-only comment at the top of it structurally true instead of a promise.Relationship to #2078
Related but not the same, and not covered by it. #2078 is about files we intend to publish that
exportsmakes unreachable — the fix there widens the public surface. This is a file we do not intend to publish that ships anyway, so the fix narrows it. It is the Sass-side counterpart of #2427, which was the same mistake in the JS bundle.Both belong to the "what is actually our public surface" question #2078 and #2427 were already circling, so it may be worth answering all three together.