8000 `swc_bundler::Bundler` with `require: true` fails to transform CommonJS modules with reassigned `module.exports` · Issue #10499 · swc-project/swc · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

swc_bundler::Bundler with require: true fails to transform CommonJS modules with reassigned module.exports #10499

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
nhaef opened this issue May 21, 2025 · 0 comments
Open

swc_bundler::Bundler with require: true fails to transform CommonJS modules with reassigned module.exports #10499

nhaef opened this issue May 21, 2025 · 0 comments
Labels
C-bug

Comments

@nhaef
Copy link
nhaef commented May 21, 2025

Describe the bug

I noticed an issue with the swc_bundler::Bundler when trying to bundle certain projects that contain CommonJS modules. I have created a minimal example project (see fork) to reproduce the issue:

// example_project/index.js
console.log(require("./42.js"));
console.log(require("./foo.js"));
// example_project/42.js
module.exports = 42;
// example_project/foo.js
module.exports = "foo";

As you can see, we are reassigning module.exports in 42.js and foo.js. According to the Node.js CommonJS module docs, reassigning module.exports is allowed. When running example_project/index.js using Node.js and Deno, both runtimes agree on the output.

> node example_project/index.js
42
foo

> deno --unstable-detect-cjs --allow-read example_project/index.js
42
foo

However, when bundling the above project with require: true (see fork), the output differs:

cargo run --example bundle -- example_project/index.js

> node output.js
{ default: 42 }
{ '0': 'f', '1': 'o', '2': 'o', default: 'foo' }

> deno --unstable-detect-cjs --allow-read output.js
{ default: 42 }
{ "0": "f", "1": "o", "2": "o", default: "foo" }

It seems that the interop function that is injected when using require: true does not handle this scenario correctly. I would be curious to hear if this is the expected behavior of swc_bundler (due to esm and cjs interop) or if this is something that should be fixed.

Thanks for looking into this!

Input code



Config




Link to the code that reproduces this issue


https://play.swc.rs/?version=1.11.24&code=H4sIAAAAAAAAA0vOzyvOz0nVy8lP1yhKLSzNLErVUNLTNzHSyypW0tS05krGriAtPx%2BqAgBI%2Bi%2FYQgAAAA%3D%3D&config=H4sIAAAAAAAAA32US5LjIAyG932KlNe9nVnMAXo3Z6AICIc0Ri4k0nF15e4jY%2BcxHTk7W59%2BCSSh77fdrjuS6%2F7svuVTfkZbCMrtXyw0ZbZnsXTgBkuuxJG79ys90oyCTQTNdFlIx7b0wE1Fv1b3LiESXN1X2xBzDNNjQofDWIDowSZWiVcHyEz%2F61dW8GsGXOqjfY%2BYwOYXxFgyMTP0ULTADlOyI4E52aJEmU9qSyTUUsywMngzFhxVnn3kiFlyPlMP1huHHhQUCziOJ9BkkktkmeR6yn0a9rCvfd%2Ba%2FEMNJ5uqZSUnnFtL5LRK1ANGYhNq1kq4wI0aLHAt7k9lDKYA15KfdUeMeaMnnwBSgWSJsh1Ai9s8gszTljq8VMYcZGR5UrjMt3bLDL0U1cQYlMrOlYHCUetmAV8dzJV12nFWvFE%2Bih4MhCCzooSmr8juoCXlaQQMCpD%2B2qBN1QLM7RVu8PlBvMAfckvWB2z1GCwftilNwx7TiwQD8AH9CwdpBeM2LrIlzuM2r9mDjAZ41aVSA89LQB4Ao0ltWT7NhjwPiWj6hPv7mlgdLrclPNjc39%2F7soffVoduQF8bXDf83N9lL%2F%2Fu7k7XLXw7eBfp71XZkl7%2BAVPL6HotBgAA


SWC Info output


No response


Expected behavior


I expected that the bundled output program behaves similar to the input program. More specifically, I expected that require('...') evaluates to the value assigned to module.exports.


Actual behavior


After bundling, require('...') no longer evaluates to the value assigned to module.exports. Instead, it returns a newObj that preserves the keys of module.exports and a newObj.default property that contains the desired value.


Version


swc_bundler 19.0.0


Additional context


No response

      		
    

      
  





        



            
            

              
            

        

      


      
    








      

    



      

  
            

    

      
    

    


      

          @nhaef
nhaef




          added
  the 

  C-bug

 label


      May 21, 2025

    

  












  
  

    

      

  





  




  
  

              

  
    Sign up for free
    to join this conversation on GitHub.
    Already have an account?
    Sign in to comment


  



  






  
                  




    

  


      
  

    Assignees
  



        

    No one assigned







      


  


  

    Labels
  



    

      

    C-bug










      


  

    
  

    Milestone
  


      No milestone





    
      
          


  

    

      
        

          
    

    Development
  




            
    
No branches or pull requests







      
    

  




      

    

  
      

  

    

      1 participant
    

    

        
          @nhaef 
    

  






    

    




    






  

          

        



    



  





    

  


  


          



    



  

    

    

    





    


    

    

  



0