Replace `export =`

[alexeyr-ci2]

export = (see https://github.com/search?q=repo%3Ashakacode%2Fshakapacker%20%22export%20%3D%22&type=code) is bad style, should be replaced by named and/or default exports. E.g. in https://github.com/shakacode/shakapacker/blob/16f6d71f6a1a071fc71da854d7014f6bf50e6620/package/index.ts we should have export const config, export const devServer etc. Unfortunately it's a breaking change, so should wait until we want to release 10.0.

Also should fully remove https://github.com/shakacode/shakapacker/blob/51aff0e8b3db6b940b9752020e72d8748018248d/package/index.d.ts (see "Background" in #775).

[justin808]

PR Ready for Review: ES Module Exports Migration

I've created PR #679 to address this issue by replacing export = with ES module exports throughout the package.

What Changed

• ✅ All export = replaced with named/default ES6 exports
• ✅ env object replaced with individual named exports (railsEnv, nodeEnv, isProduction, etc.)
• ✅ Automated migration script provided (scripts/migrate-to-esm-exports.js)
• ✅ Comprehensive migration guide (docs/v10-migration-guide.md)
• ✅ 771/773 tests passing (2 pre-existing failures)

Migration Example

Before (v9):

const shakapacker = require('shakapacker')
const config = shakapacker.config
console.log(shakapacker.env.nodeEnv)

After (v10):

import { config, nodeEnv } from 'shakapacker'
console.log(nodeEnv)

Users can run the automated migration script:

node node_modules/shakapacker/scripts/migrate-to-esm-exports.js config/webpack/

Community Feedback Requested

This is a breaking change for v10.0. Before merging, I'd like community feedback on:

1. Is this change worth the migration pain for users? The benefits are primarily:

   • Better TypeScript autocomplete and type inference
   • Clearer, more explicit imports
   • Aligns with modern JavaScript standards

2. Is the migration script sufficient? Does it cover the common use cases?

3. Should we provide backward compatibility? We could keep both export styles temporarily.

4. Documentation clarity - Is the migration guide clear enough?

Please review PR #679 and share your thoughts. If there's significant concern about breaking existing configs, we can reconsider this approach.

cc @alexeyr-ci2 (original issue author)

[justin808]

Update: Now Fully Backward Compatible! ✅

Good news - I've updated PR #679 to be 100% backward compatible. This is NO LONGER a breaking change.

Your Existing Code Still Works

// This continues to work exactly as before - no changes needed!
const shakapacker = require('shakapacker')
const config = shakapacker.config
const env = shakapacker.env
console.log(env.nodeEnv, env.isProduction)

New: Modern Import Syntax (Optional)

For new code, you can now optionally use ES6 imports:

// Named imports (optional, recommended for new code)
import { config, nodeEnv, isProduction } from 'shakapacker'
console.log(nodeEnv, isProduction)

What Changed

• ✅ Both export styles work - default export AND named exports
• ✅ Zero migration required - upgrade to v10 without changing any code
• ✅ Optional modernization - use the migration script only if you want to
• ✅ Better TypeScript - named imports provide better autocomplete (optional benefit)

Implementation

The package now exports both ways:

// Named exports (new, optional)
export { config, nodeEnv, isProduction, ... }

// Default export (keeps existing code working)
export default { config, env: { nodeEnv, ... }, ... }

This addresses the "bad style" of export = while causing zero user pain. Win-win!

cc @alexeyr-ci2