It seems like wp-scripts build includes devDependencies #79205

Activity

1. jakeparis

   added

   [Type] BugAn existing feature does not function as intendedAn existing feature does not function as intended

   on Jun 15, 2026
2. t-hamano

   added

   Needs TestingNeeds further testing to be confirmed.Needs further testing to be confirmed.

   [Tool] WP Scripts/packages/scripts/packages/scripts

   on Jun 16, 2026
3. theritiktiwari commented on Jun 17, 2026

   

   theritiktiwari

   on Jun 17, 2026

   Contributor

   More actions

   Thanks @jakeparis for reporting this issue.

   I investigated the behavior using a fresh block created with @wordpress/create-block and tested with @wordpress/scripts 32.4.1.

   What I tested

   1. Installed lodash as a devDependency.
   2. Imported and used it in the block's editor code.
   3. Ran wp-scripts build and recorded the generated bundle size and asset manifest.
   4. Moved lodash from devDependencies to dependencies.
   5. Reinstalled dependencies and rebuilt the block.
   6. Compared the generated output.

   Results

   In both cases:

   • The generated index.js bundle size remained the same.
   • The generated index.asset.php remained the same.
   • lodash was listed as a dependency in the asset file.
   • The bundle referenced window.lodash rather than bundling the library itself.

   While investigating further, I found that the dependency extraction plugin appears to determine externals based on the imported module request (e.g. lodash → lodash) and does not appear to inspect whether a package is declared under dependencies or devDependencies.

   At this point, I can reproduce the reported behavior, but I'm not yet sure whether this is an implementation bug or an expectation mismatch. Could you clarify what behavior you expect when a package is imported in runtime block code but is listed under devDependencies? Should such imports be excluded from dependency extraction and build output?
4. jakeparis commented on Jun 17, 2026

   

   jakeparis

   on Jun 17, 2026

   ContributorAuthor

   More actions

   The bundle referenced window.lodash rather than bundling the library itself.

   It might be cleaner to test with a different package (not lodash or wordpress/scripts which don't actually get packaged in favor of the globally available version).

   My Expectations:

   1. I would expect that if I have a package listed in dependency, when I run wp-scripts build, that this package would be included, since the build script is considered the production build.
   2. If I have a package listed in devDependency, when I run wp-scripts build, this package would not be included. If my production built script tried to access functionality which was included in a package included in devDeps, it would fail. because the functionality doesn't exist in the production build. That would be on me as the developer to fix that problem.
5. theritiktiwari commented on Jun 20, 2026

   

   theritiktiwari

   on Jun 20, 2026

   Contributor

   More actions

   Thanks for clarifying your expectations.

   I ran an additional test using dayjs (a package that is not externalized by the dependency extraction plugin) to rule out the special handling of packages such as lodash.

   Test setup

   1. Installed dayjs as a devDependency.
   2. Imported and used it in block code.
   3. Ran wp-scripts build and recorded the generated output.
   4. Moved dayjs from devDependencies to dependencies.
   5. Reinstalled dependencies and rebuilt.
   6. Compared the generated output.

   Results

   The generated output was identical in both cases:

   • index.js: 8629 bytes
   • Build directory size: 48 KB

   This matched the behavior I previously observed with lodash.

   From the implementation side, the build process appears to be driven by the webpack module graph (i.e. what is imported by the application code). During my investigation I wasn't able to find any logic in @wordpress/scripts or the dependency extraction plugin that changes bundling behavior based on whether a package is declared under dependencies or devDependencies.

   Given your expectations, I'd be interested in hearing whether maintainers consider this current behavior intentional, or whether wp-scripts build is expected to treat imported packages differently based on their dependency classification in package.json. If there are any prior discussions, design decisions, or documentation around this behavior, I'd be happy to review them.
6. github-actions commented on Jul 21, 2026

   

   github-actionsBot

   on Jul 21, 2026 – with GitHub Actions

   More actions

   Hi,
   This issue has gone 30 days without any activity. This means it is time for a check-in to make sure it is still relevant. If you are still experiencing this issue with the latest versions, you can help the project by responding to confirm the problem and by providing any updated reproduction steps.
   Thanks for helping out.
7. github-actions

   added

   [Status] StaleGives the original author opportunity to update before closing. Can be reopened as needed.Gives the original author opportunity to update before closing. Can be reopened as needed.

   on Jul 21, 2026
8. jakeparis commented on Jul 21, 2026

   

   jakeparis

   on Jul 21, 2026

   ContributorAuthor

   More actions

   This is still an issue. I'd like to hear whether this is expected or something that needs to be fixed. If it's expected, it wouldn't be a bad idea to add this information to the docs.
9. github-actions

   removed

   [Status] StaleGives the original author opportunity to update before closing. Can be reopened as needed.Gives the original author opportunity to update before closing. Can be reopened as needed.

   on Jul 22, 2026
10. youknowriad commented on Jul 22, 2026

    

    youknowriad

    on Jul 22, 2026

    Contributor

    More actions

    devDependencies or dependencies is strictly a npm concern and not a bundling concern. So webpack or wp-scripts will bundle whatever is imported regardless of how the dependency is defined. This is the same behavior for any bundler. So I believe this is working as intended.
11. youknowriad

    closed this as completedon Jul 22, 2026