Add option to prepend export to dotenv stringify

[bombillazo]

Is your feature request related to a problem? Please describe.

Currently, dotenv.stringify only creates Key-Value pair entries into a .env file. Sometimes we need to have the export keyword present in the .env file values

Describe the solution you'd like

Add an optional parameter to dotenv.stringify to enable this feature:

dotenv.stringify({ VALUE: 'My_Value!" }, { prefixExport: true });

// result .env
export VALUE=My_Value!

Describe alternatives you've considered

Manually editing the resulting file and appending the string... :/

[jsejcksn]

Describe alternatives you've considered

Manually editing the resulting file and appending the string... :/

@bombillazo You don't have to manually edit the file. Unless a breaking change in the implementation happens, you can automate this by transforming the result before writing the file:

const obj = { FOO: "hello", BAR: "world" };

const dotEnvString = dotenv
  .stringify(obj)
  // Prefix each line with "export "
  .split("\n")
  .map((s) => `export ${s}`)
  .join("\n");

console.log(dotEnvString === "export FOO=hello\nexport BAR=world"); // true

// Write to file…

TS Playground

…or by transforming the input instead:

const dotEnvString = dotenv.stringify(
  Object.fromEntries(
    Object.entries(obj).map(([k, v]) => [`export ${k}`, v])
  ),
);

TS Playground

The previous approach, but using std/collections/map_keys.ts:

const dotEnvString = dotenv.stringify(
  mapKeys(obj, (k) => `export ${k}`),
);

TS Playground

[timreichen]

I think this would be a good addition.
But there are multiple ways to go about this and also some problems when arguing that parse() and stringify() should be exact opposite functions that reverse each step exactly.

Adding an option which takes a list of exported keys:

stringify({ FOO: "bar" }, { exports: ["FOO"] })

or adding an export property:

stringify({ FOO: { value: "bar", export: true } })

For an exact reversal function, the current parse() implementation is inadequately designed because it is lossy. It doesn't distinguish between exported and non-exported keys.

So the reversal would mean either

const { data, exports } = parse("export FOO=bar")
// data: { FOO: "bar" }
// exports: ["FOO"]

or

const data = parse("export FOO=bar")
// data: { FOO: { value: "bar", export: true }

Imo the second approach is better. That would also mean a breaking change in the dotenv API.

[bombillazo]

Those are nice considerations. Perhaps another separate method can be added for this advanced parsing/stringifying?

I think the current API is very convenient, simple, and sweet for most cases. I'm not sure about the Deno convention for these types of enhanced methods, but forcing the more complex response as the default may make the API usage more verbose and complicated.

[bombillazo]

@jsejcksn Hey! Thats exactly how we are currently handling this. It works and one has complete control on which functions to export or not in the map function. :)