Resulting code is not from Babel

[Klustre]

The resulting Babel code is somehow transformed after the plugin ran.

I have been trying to figure out the problem but haven't found the solution yet. The relevant test ternary statement is const a = false ? false ? 1 : 2 : 3. After esbuild-plugin-babel's onLoad is called and the content is transformed, I log the results in the onLoad callback and get var a = false ? (false ? 1 : 2) : 3; for that line—which is good. I also double checked with babel.transform to make sure the extendscript preset works well.

But when I check the final esbuild output file, the brackets disappeared. I am somewhat aware that the plugins for esbuild aren't the last line of bundling process, so it probably modified the babel output and removed the brackets. I am not too familiar with what goes on in esbuild between calling the plugins and writing to output, but it would be helpful if you might know the answer.

See https://github.com/fusepilot/babel-preset-extendscript/issues/15

Possible solution: https://github.com/evanw/esbuild/issues/1010#issuecomment-803865232

[donaldzhu]

I am able to make Babel's code the resulting output if I first put esbuild's output in a temporary folder, then have Babel watch and transform those files with extendscripts preset. However, if I want to include core.js polyfills (i.e. Array.includes), I will have to pre-Babel with esbuild-plugin-babel since it generates imports that needs to be bundled, then build with esbuild, then post-Babel again with extendscript.

One current problem I am running into right now is that core.js generates regex with unescaped forward slashes (/function\b(?:\s|\/\*[\S\s]*?\*\/|\/\/[^\n\r]*[\n\r]+)*([^\s(/]*)/), which throws Expected: ; when run. The main problematic portion I am testing with is var foo = /[/]/, which throws the same error due to the forward slash. I am not too familiar with esbuild or Babel, so if you know how to make either of them escape forward slashes in regex it would be helpful.

[Klustre]

This is exactly why babel-preset-extendscript is used because core-js uses polyfills (which alter the prototype) and generates code that is incompatible with Extendscript.

I'm interested to see your core-js setup though, because it might lead to a better solution than babel-preset-extendscript. Could you make an example repo for it?

[donaldzhu]

I am not too sure what you mean by more core-js setup. I put the following in plugins prop for esbuild:

babel({
  filter: /[^.text].js/,
  config: {
    presets: [
      ['@babel/preset-env', {
        modules: false,
        useBuiltIns: 'usage',
        corejs: '3.26'
      }]
    ]
  }
})

This is the pre-Babel that's supposed to help with polyfill. I am presuming the other incompatibilities between core-js and extendscript should be ironed out by babel-preset-extendscript in the post-Babel process. It could work if babel-preset-extendscript just escapes forward slashes in regex to make it work with core-js.

As I have dug deeper into babel-preset-extendscript, I realized it's an extension that's no longer maintained, and I have been encountering bugs that I personally don't have the know-how to fix (i.e. this most recent issue). When I have more time, I will look for other transpilers that transpile to es3 as potential replacement for babel-preset-extendscript. For now, I am planning to skirt around with my own poly/ponyfill, which means I can't use external npm packages since they sometimes cause issues with extendscript.