export cli folder

[bingtsingw]

Why?

Before adding exports to the package.json, I have a file import the cli like this import '@dotenvx/dotenvx/src/cli/dotenvx.js';

But after adding the exports field, it reports error: Package subpath './src/cli/dotenvx.js' is not defined by "exports"

So, I add a cli exports in this pr, so that I can now import the cli like this import '@dotenvx/dotenvx/cli/dotenvx.js'; without error.

[motdotla]

hmm, i'm initially hesitant to do this because then next thing people will be asking for a types file to go with this dotenvx.js cli file. it's not really designed to be used in code - it's designed as a cli - and the lib/main is designed to be used in code. lib/main exposes most of the same functions.

can you elaborate on why you are using the cli this way? why import it?

that will help me decide if we should do this or not.

[bingtsingw]

I have wrote a lib to pack my frequently used packages, so that I can only install @xstools-dev/mix to use them all. In order to achieve this, I have to re-export the binaries like this way.

This is indeed an uncommon usage, but I'm not sure if there is a better way.

[motdotla]

i see. yeah, this is sort of a downside to choosing ESM. on the dev's side (yours in this case) you need to reach out to the maintainer to export the internal file. on the maintainers side (mine) it adds work and removes flexibility (this is somewhat a private/internal file) by exporting these files. it also can go on forever if someone wants to import some other internal file.

there are some options:

1. consider switching to common js (though i doubt that is what you want here)
2. use execa in your bin script. something like this:

#!/usr/bin/env node

import { execa } from 'execa'
execa('npx', ['dotenvx', ...process.argv.slice(2)], { stdio: 'inherit' })

3. I think you might be able to use require.resolve but i couldn't get it to work
4. you might be able to use patch-package to apply this additional exports to your installed dotenvx module.
5. maintain your own fork

All options are less than ideal, but I think that is where we have to land here. I don't want to get into the hairiness of maintaining an export for this at this time - maybe someday in the future I will change my mind.