Support --format= when without bundle

[CompuIves]

First of all, this is an incredible project. I'm really impressed with the speed!

I'm trying to run esbuild --format=cjs add.js on

import createMathOperation from './_createMathOperation.js';

var add = createMathOperation(function(augend, addend) {
  return augend + addend;
}, 0);

export default add;

But the output is

import createMathOperation2 from "./_createMathOperation.js";
var add = createMathOperation2(function(augend, addend) {
  return augend + addend;
}, 0);
export default add;

Is this intended? Or should it only work with --bundle?

My use case is that I'm looking for a quick transformer that can transform an esmodule to commonjs, I'm wondering if esbuild could do something like this.

[evanw]

It's a good idea. I've been planning to do this but haven't gotten to it yet. It should be fairly straightforward. However, the whole bundling transform is currently being rewritten to support tree shaking and code splitting. So I'm going to wait to do this until after that is done.

[WenheLI]

Any updates on the cjs output?
I also want to output a project in cjs format.

[evanw]

I just landed a change that implements this. There are some details in the release notes.

I decided to not implement CommonJS to ECMAScript module conversion for now. There are a few different options and it's not immediately clear to me how to implement it. I'm not sure if there's a single way to implement it that would satisfy all use cases, or even what the majority use case is. Some of my open questions:

• What environments and situations is this useful in? I think perhaps the browser is one of them, but this seems to me like something that would be pretty custom per app and wouldn't really be appropriate to build into esbuild's core.

• Naive conversion of require() to import is imprecise because it potentially changes the execution order, which could introduce bugs. How much do people care about these bugs? What do people usually do to fix them? For example, this could be worked around by translating CommonJS to an ECMAScript module that exports a "require function" to invoke to call it. But that likely wouldn't work well with existing tooling.

• Conversion of require() to import doesn't work if the path string cannot be statically determined. And require() cannot be converted to import() because import() returns a promise. One potential solution could be to only support these require() calls in async functions (or at the top level) and convert it to an await import() (or top-level await). But that likely wouldn't work for most CommonJS modules that contain dynamic require() calls. Another potential solution could be to convert it to something that uses createRequire:

  import {createRequire} from 'module'
  const require = createRequire(import.meta.url)

  But that would only work with node, not in other environments. And it's unclear what to use in place of import.meta.url because the generated file may live in a separate place from the source file. Another solution could be to leave require alone and polyfill it at run time instead (e.g. with a synchronous XHR or preloaded list of modules).

Anyway, CommonJS to ECMAScript module conversion seems sufficiently complex and full of pitfalls that it looks like it isn't something that belongs in esbuild's core to me. At least not until I have more data.

[yorkie]

@evanw when will this feature be released?

[evanw]

@evanw when will this feature be released?

Sometime later tonight. I recently discovered some unrelated correctness issues that I want fix too.

[evanw]

It has now been released as version 0.6.32. Please let me know if you encounter any issues.