Esm: ESM_OPTIONS usage

[okwolf]

I'm trying to use the new ESM_OPTIONS available in 0.18.0 and having some issues. I don't see any working usage examples in the README, release notes, or #139. I'm guessing based on the unit tests for this feature that ESM_OPTIONS=cjs should be supported, but that's not the behavior I'm seeing. Using "@std/esm": "cjs" in package.json does work, however.

I made a repo that shows the issue, including a branch demonstrating the package.json property alternative working: https://github.com/okwolf/esm-options.

I look forward to having my obvious oversight on this matter pointed out. I would also encourage including an example of how to properly use this feature for the common cjs use case.

[jdalton]

Np @okwolf! The use of completely unquoted values like ESM_OPTIONS=cjs will be supported in the next release. At moment only unquoted object keys are allowed.

[okwolf]

Thanks for the reply @jdalton. So does that mean that any of the following should work?

ESM_OPTIONS='cjs'
ESM_OPTIONS="cjs"
ESM_OPTIONS={cjs:true}
ESM_OPTIONS={esm:'js'}
ESM_OPTIONS={esm:"js"}
ESM_OPTIONS={esm:'js',cjs:true}
ESM_OPTIONS={esm:"js",cjs:true}

I've tested each and none of them seem to work either 🤔

[jdalton]

Hmm okay!

It seems to be giving the default config priority over the environment var. Looking into it.

Update:

*Boop* https://github.com/standard-things/esm/commit/f4a645251975a727c7c923164f7df39df2a8746d. I'll follow up with another test.

[okwolf]

@jdalton thanks for looking into this! I've tested with the latest build from master and it works 👍

What's the timeline looking like for a new release? Are there any other bugs/features being worked on?

[jdalton]

@std/esm v0.19.0 is released :tada: