# [RFC] Migrate from Webpack to Rspack for 80% faster builds

[ALWISHARIFF]

Summary

I propose migrating Goji.js from Webpack 5 to Rspack to significantly improve build performance while maintaining full compatibility. Rspack is a Rust-based bundler with 80%+ Webpack plugin compatibility that can deliver 60-80% faster builds with minimal code changes.

Motivation

Current Pain Points

• Slow development builds - Especially in large projects with many components
• Slow HMR (Hot Module Replacement) - Takes 5-10+ seconds for changes to reflect
• High memory usage - webpack can consume 1GB+ in large projects
• Slow production builds - Can take several minutes for complex apps

Why Rspack (and NOT Turbopack)?

• ✅ Rspack supports 80%+ of Webpack plugins including @goji/webpack-plugin
• ✅ Production ready - Used by TikTok, Microsoft, Amazon, Discord
• ✅ Uses SWC internally - Automatic performance benefits
• ✅ Drop-in replacement - Minimal API changes needed
• ❌ Turbopack does NOT support Webpack plugins - Would require complete rewrite of @goji/webpack-plugin

Expected Performance Improvements

Based on real-world Rspack migrations:

Metric	Webpack 5	Rspack	Improvement
Dev build (first)	~30s	~6s	80% faster
Dev build (cached)	~5s	~1s	80% faster
Prod build	~120s	~24s	80% faster
HMR	5-10s	<1s	90% faster
Memory usage	~1.2GB	~720MB	40% less

Proposed Changes

1. Package Changes

Remove:

{
  "webpack": "^5.x",
  "webpack-cli": "^5.x",
  "terser-webpack-plugin": "^5.x",
  "mini-css-extract-plugin": "^2.x"
}

Add:

{
  "@rspack/core": "^1.x",
  "@rspack/cli": "^1.x"
}

Keep (should work as-is):

• @goji/webpack-plugin - Core plugin for Mini Program transformations
• babel-loader - For JavaScript/TypeScript transpilation (or replace with SWC)
• linaria - CSS-in-JS
• postcss-loader, css-loader - CSS processing
• All other loaders and dependencies

2. Configuration Changes

File: packages/cli/src/config/webpack.config.ts → rspack.config.ts

Key changes:

// Before (Webpack)
import webpack from 'webpack';
import TerserPlugin from 'terser-webpack-plugin';
import MiniCssExtractPlugin from 'mini-css-extract-plugin';

// After (Rspack)
import { rspack } from '@rspack/core';
import type { RspackOptions } from '@rspack/core';
// TerserPlugin and MiniCssExtractPlugin are built-in!

Minification:

// Before (Webpack + Terser)
minimizer: [
  new TerserPlugin({
    terserOptions: {
      format: { comments: false },
      compress: { passes: 2 },
    },
    extractComments: false,
    parallel: parallel?.minimize,
  }),
]

// After (Rspack + SWC)
minimizer: [
  new rspack.SwcJsMinimizerRspackPlugin({
    minimizerOptions: {
      compress: { passes: 2 },
      mangle: true,
      format: { comments: false },
    },
  }),
]

CSS Extraction:

// Before
new MiniCssExtractPlugin({ /* ... */ })
use: [MiniCssExtractPlugin.loader, 'css-loader', ...]

// After
new rspack.CssExtractRspackPlugin({ /* ... */ })
use: [rspack.CssExtractRspackPlugin.loader, 'css-loader', ...]

Plugin Updates:

// These stay the same, just change the import
new rspack.DefinePlugin({ /* ... */ })
new rspack.ProvidePlugin({ /* ... */ })
new rspack.ProgressPlugin()

3. Optional: Replace Babel with SWC (20x faster transpilation)

// Current (babel-loader)
{
  test: /\.(js|jsx|ts|tsx)$/,
  use: [
    ...threadLoaders, // Can be removed - Rspack is parallel by default
    {
      loader: require.resolve('babel-loader'),
      options: { ...babelConfig, cacheDirectory: true },
    },
  ],
}

// Proposed (builtin:swc-loader)
{
  test: /\.(js|jsx|ts|tsx)$/,
  use: [
    {
      loader: 'builtin:swc-loader',
      options: {
        jsc: {
          parser: { syntax: 'typescript', tsx: true, decorators: true },
          transform: {
            react: { runtime: 'automatic', development: nodeEnv === 'development' },
          },
          target: 'es2015',
        },
        env: {
          targets: { ios: '9', android: '5' },
          mode: 'usage',
          coreJs: '3',
        },
      },
    },
  ],
}

Note: If @goji/macro or other Babel plugins are critical, we can use a hybrid approach:

• Use SWC for 95% of files (fast)
• Use Babel only for files with macros (compatibility)

4. Remove Obsolete Code

• thread-loader - Rspack is parallel by default
• Complex cache identifiers - Rspack has simpler caching
• parallel options - Built-in and automatic

Compatibility Considerations

Likely to Work (High Confidence)

✅ @goji/webpack-plugin - Standard Webpack plugin API
✅ linaria - Loader-based, should work fine
✅ postcss-loader - Standard loader
✅ css-loader - Standard loader
✅ Custom loaders (@goji/webpack-plugin/dist/cjs/loaders/transform)
✅ All Mini Program targets (WeChat, Alipay, Baidu, Toutiao, QQ)

May Need Testing

⚠️ babel-plugin-macros with SWC - May need to keep Babel for macro files
⚠️ Custom Webpack hooks - Need to verify Rspack compatibility
⚠️ Complex chunk splitting - Should work but needs verification

Fallback Plan

If @goji/webpack-plugin has compatibility issues:

1. Create a thin wrapper/adapter for Rspack
2. Work with Rspack team on compatibility fixes
3. Keep both webpack.config.ts and rspack.config.ts for gradual migration

Implementation Plan

Phase 1: Proof of Concept (Week 1)

• Create feature branch feat/rspack-migration
• Install Rspack alongside Webpack
• Create initial rspack.config.ts based on webpack.config.ts
• Test basic build for one target (e.g., WeChat)
• Document any compatibility issues

Phase 2: Full Migration (Week 2)

• Update all build scripts
• Test all Mini Program targets (WeChat, Alipay, Baidu, Toutiao, QQ)
• Verify in respective Mini Program IDEs
• Compare output bundles (size, structure)
• Run existing test suite
• Update CI/CD pipelines

Phase 3: Optimization (Week 3)

• Replace babel-loader with SWC (if compatible)
• Fine-tune cache configuration
• Optimize source map settings
• Benchmark performance improvements
• Update documentation

Phase 4: Rollout (Week 4)

• Create comprehensive migration guide for users
• Update README with new build instructions
• Update contributing guidelines
• Publish beta release for community testing
• Gather feedback and address issues
• Stable release

Testing Checklist

• Development builds work correctly
• Production builds work correctly
• Hot Module Replacement (HMR) functions properly
• Source maps generate correctly
• CSS transformations work (px → rpx, etc.)
• Code splitting works for subpackages
• Asset handling works (images, fonts, etc.)
• All Mini Program targets build successfully:
  • WeChat (wechat)
  • Alipay (alipay)
  • Baidu (baidu)
  • Toutiao (toutiao)
  • QQ (qq)
• Output loads in respective IDEs:
  • WeChat DevTools
  • Alipay IDE
  • Baidu IDE
  • Toutiao IDE
  • QQ IDE
• Existing test suite passes
• Performance benchmarks show improvement

Rollback Strategy

If critical issues are found:

1. Keep both configurations during transition period
2. Use environment variable to switch between bundlers:

   {
     "scripts": {
       "dev": "rspack serve",
       "dev:webpack": "webpack serve",
       "build": "rspack build",
       "build:webpack": "webpack build"
     }
   }

3. Document blockers for future attempts
4. Collaborate with Rspack team on plugin compatibility

Success Metrics

Performance

• Development build time reduced by 60-80%
• Production build time reduced by 70-85%
• HMR latency reduced to <1 second
• Memory usage reduced by 20-40%

Compatibility

• All existing features work correctly
• All Mini Program targets build successfully
• Output bundles are equivalent or better
• No regressions in functionality

Developer Experience

• Faster feedback loop during development
• Better build caching
• Improved error messages (Rust-based tooling)
• Maintained or improved debugging experience

Documentation Updates Needed

• Update README.md with Rspack instructions
• Update CONTRIBUTING.md with new build process
• Create MIGRATION.md for users upgrading
• Update CLI documentation
• Update webpack.config.ts comments/docs
• Add Rspack troubleshooting guide

Community Impact

Benefits

• Faster development for all Goji.js users
• Lower resource usage - Better for older machines
• Modern tooling - Rust-based ecosystem
• Better caching - Faster incremental builds
• Continued momentum - Rspack is actively developed

Risks

• Breaking changes - Users need to update their projects
• Plugin incompatibility - Some edge cases may need workarounds
• New bugs - Rspack is newer than Webpack
• Community familiarity - Webpack is more widely known

Migration Path for Users

For existing Goji.js projects:

1. Update @goji/cli to version with Rspack support
2. No changes needed - Rspack is drop-in replacement
3. Optional: Update custom configurations if any
4. Enjoy faster builds! 🚀

Alternative Approaches Considered

Option 1: Turbopack

• ❌ Rejected - Does not support Webpack plugins
• Would require complete rewrite of @goji/webpack-plugin
• Plugin API not available until Q2 2026 (future)

Option 2: Keep Webpack but use SWC

• ✅ Partial improvement - Only speeds up transpilation
• Still limited by Webpack's bundling performance
• Rspack gives all these benefits plus faster bundling

Option 3: esbuild

• ⚠️ Plugin ecosystem - Limited compared to Webpack/Rspack
• Would require rewriting @goji/webpack-plugin for esbuild API
• Less compatible with existing Webpack plugins

Option 4: Vite

• ⚠️ Different architecture - Rollup-based, not Webpack-compatible
• Would require significant architectural changes
• Better suited for web apps than Mini Programs

Conclusion: Rspack is the best option for Goji.js because it offers the best balance of performance improvement, compatibility, and migration effort.

Questions & Concerns

1. Will @goji/webpack-plugin work with Rspack?

   • Very likely - Rspack supports 80%+ of Webpack plugins
   • Will verify during POC phase
   • Fallback: Create compatibility wrapper if needed

2. What about babel-plugin-macros?

   • Can keep Babel for macro files only
   • Use SWC for everything else (hybrid approach)

3. Will this break existing projects?

   • No - Migration will be in @goji/cli only
   • Users get benefits by updating their CLI version
   • Backwards compatible approach

4. What if we find critical issues?

   • Keep Webpack config as fallback
   • Work with Rspack team on fixes
   • Can always revert if needed

Resources

• Rspack Documentation
• Rspack Migration Guide
• Rspack Plugin Compatibility
• Rspack GitHub
• SWC Documentation

I'd Like to Contribute

I'm interested in taking on this migration and would like to:

1. Create a POC to validate compatibility
2. Work with maintainers on the implementation approach
3. Submit PRs for the migration
4. Help with testing across all Mini Program targets
5. Write documentation for the migration

I've already prepared:

• ✅ Complete Rspack configuration based on existing webpack.config.ts
• ✅ Detailed migration guide
• ✅ Side-by-side comparison of changes needed
• ✅ Testing checklist and rollback strategy

I'm happy to collaborate with the team and iterate on this proposal. Please let me know if you'd like me to proceed with a POC or if you have any concerns/suggestions!

---

Expected Timeline: 4 weeks from approval to stable release
Effort: Medium (mostly configuration changes, minimal code changes)
Risk: Low (can fallback to Webpack if needed)
Impact: High (significant performance improvements for all users)

cc: @maintainers - Would love to hear your thoughts on this proposal! 🚀