Repository navigation
feat(barrel-policy): accept a package's declared entry files as barrels - #136
Conversation
A package that publishes subpath exports has a module behind each one, and that module is an entry point just as src/index.ts is. 'single' treated only src/index.ts as a barrel and 'siblings' only accepted re-exports from a direct sibling, so the only way to lint such a package was to turn the rule off for its entry files, which also stopped checking that they hold only re-exports. The new entries option lists the entry files as globs relative to the nearest package.json. A matched file is a permitted barrel: it may hold only re-exports, from anywhere in 'single' and from a package or a direct sibling in 'siblings'. Every other file keeps its mode's behaviour, and the default is unchanged. entries beside mode 'banned' is rejected when the rule is created, and under 'auto' resolved to 'banned' the list selects nothing. The list is explicit rather than derived from package.json exports, because an exports target names the built file and mapping it back to its source depends on build configuration the rule cannot read. Fixes #135
The react and nextjs getters return arrays built from several upstream blocks, but PublicPlugin typed every config as a single object or an array, so spreading them, as an array is used, failed with TS2488. recommended and barrel are now typed as single config objects and react and nextjs as arrays, matching the getters, whose own return types are narrowed the same way. A consumer-compatibility check spreads both arrays into defineConfig, and a test pins that recommended cannot be spread. Fixes #134
|
@codex security review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
🛡️ Codex Security ReviewSecurity review completed. No security issues were found in this pull request. Reviewed commit: Only the user who started this review can view the report in Codex. ℹ️ About Codex security reviews in GitHubThis is an experimental Codex feature. Security reviews are triggered when:
Once complete, Codex will leave suggestions, or a comment if no findings are found. |
|
🎉 This PR is included in version 3.1.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Adds an
entriesoption toexadev/barrel-policyso a package that publishes several entry points can declare them, instead of turning the rule off for those files.The globs are relative to the nearest
package.json, so one shared config works across a workspace. A matched file is a permitted barrel: it may contain only re-exports, from anywhere insingle(assrc/index.tsmay) and from a package or a direct sibling insiblings. Files the list does not match behave exactly as before, and nothing changes for a config withoutentries.entrieswithmode: 'banned'throws when the rule is created; underautoresolved tobannedthe list selects nothing.I chose an explicit list over deriving entries from
exports: the targets there are built files (./dist/layout.js), and the source behind each depends on tsdown, tsc or bundler configuration the rule can't see. The README section on package entry points explains this.With this, ExaDev/process-graph#41 can replace its
"exadev/barrel-policy": "off"block withentrieslisting its subpath modules.Also fixes the
plugin.configs.react/nextjstyping from #134: they are now typed as the arrays the getters return, sodefineConfig(...plugin.configs.react)typechecks. A compatibility check spreads both, and a test pins thatrecommendedstays a single object.Fixes #135
Fixes #134