-
-
Notifications
You must be signed in to change notification settings - Fork 100
Open
Labels
Description
Build tools should be in dependencies, not devDependencies
Problem
Currently, Shakapacker's package.json has build tooling (webpack, rspack, loaders, plugins) in devDependencies instead of dependencies. This creates several issues:
1. Production Builds May Fail
When Shakapacker is installed in a production environment or during deployment:
npm install --productionskipsdevDependencies- Build tools like webpack, rspack, swc-loader, babel-loader, etc. are not installed in Shakapacker's
node_modules - If the consuming application relies on Shakapacker's bundled tools (via resolveLoader or similar), the build will fail
2. Inconsistent Behavior Between Environments
- Development (with
npm install): Build tools are present innode_modules - Production (with
npm install --production): Build tools are missing - CI/CD: Behavior depends on whether
NODE_ENV=productionis set
3. File Path Dependencies Issue
When using Shakapacker via a local file path (e.g., during development with "shakapacker": "file:../shakapacker"):
- Webpack's
resolveLoadercan find loaders likeswc-loaderin Shakapacker'snode_modules(because devDependencies are installed) - But those loaders may fail to find their own dependencies (like
@swc/core) because peer dependencies don't get installed in nestednode_modules - This led to the workaround of adding
@swc/coreto devDependencies (commit 2015f79)
Current State
{
"dependencies": {
"js-yaml": "^4.1.0",
"path-complete-extname": "^1.0.0",
"webpack-merge": "^5.8.0"
},
"devDependencies": {
"@rspack/cli": "^1.4.11",
"@rspack/core": "^1.4.11",
"@swc/core": "^1.3.0",
"babel-loader": "^8.2.4",
"compression-webpack-plugin": "^9.0.0",
"css-loader": "^7.1.2",
"esbuild-loader": "^2.18.0",
"mini-css-extract-plugin": "^2.9.4",
"rspack-manifest-plugin": "^5.0.3",
"sass-loader": "^16.0.5",
"swc-loader": "^0.1.15",
"webpack": "5.93.0",
"webpack-assets-manifest": "^5.0.6",
"webpack-subresource-integrity": "^5.1.0",
// ... plus ESLint, TypeScript, Jest, etc.
},
"peerDependencies": {
// Same build tools listed here (correct)
}
}Proposed Solution
Move runtime build tools from devDependencies to dependencies:
Should be in dependencies:
- All bundler cores:
webpack,@rspack/core,@rspack/cli - All loaders:
babel-loader,swc-loader,esbuild-loader,css-loader,sass-loader - All plugins:
mini-css-extract-plugin,compression-webpack-plugin,webpack-assets-manifest,rspack-manifest-plugin,webpack-subresource-integrity - Loader peer deps that are commonly resolved from Shakapacker's node_modules:
@swc/core(added in 2015f79)
Should remain in devDependencies:
- TypeScript compiler and type definitions:
typescript,@types/* - Linting and formatting:
eslint,prettier,eslint-* - Testing:
jest,@jest/* - Development tooling:
husky,lint-staged
Should remain in peerDependencies:
- All build tools (so consuming apps know they need to install them)
- Keep all as
optional: trueinpeerDependenciesMeta
Impact
Breaking Change?
This could be considered a breaking change if:
- Some users are relying on
npm install --productionNOT installing build tools - Bundle size increases for published package
However, this is more of a bug fix because:
- The current setup breaks production builds in certain configurations
- It creates inconsistent behavior between development and production
- The
peerDependenciesalready declare these as requirements
Migration Path
- Move packages from
devDependenciestodependencies - Update documentation to explain that build tools are bundled
- Consider if this should be a major version bump (10.0.0) or a minor/patch
Related Issues
- Caused the
@swc/coreresolution issue that required commit 2015f79 - May explain issues users have reported with production builds
- Related to the general peer dependency resolution strategy
References
- Commit 2015f79: "Add @swc/core to devDependencies" (workaround for this issue)
- Similar discussion in other build tool integrations (Vite, etc.)