How to echo active config and verify plugins in use?

[davidcoleman007]

while debugging a babel-node issue in our repository (https://github.com/adobe/react-spectrum) I found a use case where i was not sure what config was being used by one of our babel-node commands.

After investigating the available cli options, I see that there is no way for babel-node to echo the active config, either the path or the whole config. My issue is that i have specified some plugins on the command line:
babel-node --extensions '.cjs,.js' --experimental-modules --presets @babel/env --plugins @babel/plugin-transform-modules-commonjs ./packages/@spectrum-icons/express/scripts/generateIcons.cjs -i '[]'

the command above works fine executed as is with npx, however when it is executed w/in a js script by concurrently, it fails to use the specified plugin... but only on windows (we have verified with multiple windows machines). why?

How can i echo and verify which plugins the failing invocation may be using? I would like to verify that indeed babel-node is or is not using the specified plugin to guide my next steps.

how to reproduce:
clone https://github.com/adobe/react-spectrum on windows, and try to do a yarn install. the make-icons step fails. It succeeds on macs and linux.

I do not know if this is some issue of ours or if there is some issue causing babel-node to not pick up the plugin specified at the command line. so i would like to know, "how can i debug babel node and determine if it is indeed actually NOT using that plugin despite it being specified, in my use case?"

[JLHwung]

Can you try running babel node with the environment variable BABEL_SHOW_CONFIG_FOR=/path/to/your/input? It should print the effective config to stdout, see also https://babel.dev/docs/configuration#print-effective-configs

[davidcoleman007]

@JLHwung
that seems to be "working" but echo's no config:

later on, the babel-node command fails with the following error:

despite the fact that we ran it as:
babel-node --extensions '.cjs,.js' --presets @babel/env --plugins @babel/plugin-transform-modules-commonjs ./scripts/generateIcons.cjs

have i missed something? does this imply that babel-node is somehow running in a pure configuration-less mode?

we spawn our builds using cocurrently and - again, most oddly - this fails only on windows.

https://github.com/adobe/react-spectrum/blob/main/scripts/buildIcons.js#L47

on mac's and linux the import's are processed as expected... but i'm frankly more surprised that it works than that it fails... no where have we actually specified that we should use the @babel/plugin-transform-modules-commonj which seems necessary for this to succeed on any platform.

edit: in my current local copy i'm trying to add the usage of this plugin, with - as in my post - confusing results. The goal here is to support windows developers as contributors to our project.

[JLHwung]

The commonjs transform should be loaded by preset-env specified in the top level Babel config: https://github.com/adobe/react-spectrum/blob/3f646a021b6e1996ba6d3df2cf1eec393459989c/babel.config.json#L5 so the mac/linux build should work.

babel-node --extensions '.cjs,.js' --presets @babel/env --plugins @babel/plugin-transform-modules-commonjs ./scripts/generateIcons.cjs

This command looks good to me, I have no idea why it fails on Windows. It does seem like for some reason the programmatic options are ignored.

You can try to remove the --extensions setting, as it has been covered by the default extensions ".js", ".jsx", ".es6", ".es", ".mjs", "cjs".

Unfortunately I don't have a windows machine in hand.

[davidcoleman007]

It does seem like for some reason the programmatic options are ignored.

it seems the same for me.

although i have managed to workaround my immediate issue by upgrading yarn (as mentioned in another thread), i do think that potentially this may be a babel-node bug.

What could be the reason that babel-node would be ignoring my programmatic options? How can i debug further?

[JLHwung]

Did you try removing the --extensions? I am wondering if the .cjs,.js is somehow not recognized as two extensions, in this case babel-node will not handle *.js at all.

[davidcoleman007]

i'll do that to rule it out right now. ⌛

[davidcoleman007]

well then. That indeed was the issue.

that's good. I didn't want to have to recommend to the team to upgrade from yarn v1 to yarn v4. that would have been a difficult conversation.

... pausing ... let me check if the yarn v1 version was at all a culprit.

original issue was posted with yarn 1.22.19

after rollback from v4, i end up on 1.22.22, i tested a clean install on both yarn v1.22.19 and yarn v1.22.22 and for both cases, removing babel-node --extensions '.cjs,.js' solved the issue. preset/env is picked up from cli and cjs imports are now processed as expected.

Thus it seems that it's a case where specifying this causes all other options to be ignored. Does this qualify as a babel-node bug?

What i am left not understanding is how yarn v4 built it WITH babel-node --extensions '.cjs,.js' regardless of these findings with yarn v1, and how it worked from the command line with the command i posted? how is yarn v1 + babel-node special (on windows)?

[liuxingbaoyu]

Maybe the way yarn executes scripts has changed. You can try babel-node --extensions \".ts,.tsx\" to see if it works.

[JLHwung]

Tip: you probably don't have to specify --presets @babel/env at all. babel-node should pick up the babel config in babel.config.json automatically. If scripts are only executed on Node.js, you can further specify the targets option within an overrides clause so that preset-env will only enable plugins required by Node.js 18.17 for any files under scripts:

{
  "overrides": [{
    "include": "scripts",
    "targets": "node 18.17"
  }]
}

[liuxingbaoyu]

I ran yarn on my local Windows and it did not throw an error.
Note: I upgraded yarn to v4 because yarn 1 had a bug and did not work on my local machine.

[davidcoleman007]

interesting. I am indeed using yarn v1.22.19

[davidcoleman007]

i will try with yarn 3

[liuxingbaoyu]

Sorry, I misspoken, it was actually yarn v4. :)

[davidcoleman007]

thank you @liuxingbaoyu ❤️ Yarn v4 appears that it was the answer

Thank you, babel-community, for helping so willingly!