Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: add environment variables specification #52735

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

IlyasShabi
Copy link
Contributor

@IlyasShabi IlyasShabi commented Apr 28, 2024

Following #49148
Add documentation for environment variables specifications

@nodejs-github-bot nodejs-github-bot added doc Issues and PRs related to the documentations. process Issues and PRs related to the process subsystem. labels Apr 28, 2024

6. **Multiline values**:

* Values enclosed in double, single, or backtick quotes that span multiple
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Values enclosed in double, single, or backtick quotes that span multiple
* Values enclosed in quotes described above that span multiple

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may also make sense to mention that unlike shells " and ' behave identially. In shells typically ' doesn't interpolate anything, " allows inline interpolation and backticks execute a command in a subshell.

```cjs
const assert = require('node:assert');
const process = require('node:process');
assert.strictEqual(process.env.MULTI_DOUBLE_QUOTED, 'double\nquoted');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need to escape all \ characters

Suggested change
assert.strictEqual(process.env.MULTI_DOUBLE_QUOTED, 'double\nquoted');
assert.strictEqual(process.env.MULTI_DOUBLE_QUOTED, 'double\\nquoted');

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

@GeoffreyBooth GeoffreyBooth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have two general concerns with this PR:

  1. This is a lot of text to introduce and then need to maintain; we’re essentially defining our own specification here. Is this specified somewhere already that we can just link to?

  2. What happens when we want to add a new feature that’s not specified, like string interpolation? We just update this spec? Would that be a breaking change?


```bash
# COMMENTS=work
INLINE_COMMENTS=inline comments # work
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the space after comments part of the value of INLINE_COMMENTS?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@GeoffreyBooth No, we trim spaces in both the key and the value

This section describes how the environment variables file parser reads a file
and sets up the environment variables in Node.js.

1. **Basic parsing**:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The docs generally avoid bold. Rather than this being a numbered list you could make subheadings:

Suggested change
1. **Basic parsing**:
#### Basic parsing

assert.strictEqual(process.env.INLINE_COMMENTS, 'inline comments');
```

3. **Whitespace handling**:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would list this second, above comments.

Comment on lines 2505 to 2506
* Any `export` keyword before a key is ignored, allowing compatibility with
shell scripts.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I initially read this as saying that any lines beginning with export get ignored, not that just the export keyword alone is ignored.

Suggested change
* Any `export` keyword before a key is ignored, allowing compatibility with
shell scripts.
* Any `export` keyword before a key is ignored, allowing compatibility with
shell scripts. The line is parsed as if `export` wasn't there.

@anonrig
Copy link
Member

anonrig commented May 23, 2024

@IlyasShabi are you interested in continuing on this? this is the only missing PR from making dotenv stable.

@IlyasShabi
Copy link
Contributor Author

@anonrig sorry for the delay I was on holidays, yes will work on it this weekend.

@IlyasShabi
Copy link
Contributor Author

@GeoffreyBooth AFAIK, the only documentation for parsing env files is from the dotenv package https://github.com/motdotla/dotenv

For adding new features we should update this document. If the changes are breaking, we need to document them clearly.
Do you have some suggestions ?

Copy link
Member

@RedYetiDev RedYetiDev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed

@anonrig
Copy link
Member

anonrig commented May 26, 2024

@RedYetiDev your comment is not really helpful or contain any actionable item. please provide direct suggestions.

@anonrig
Copy link
Member

anonrig commented May 26, 2024

I have two general concerns with this PR:

  1. This is a lot of text to introduce and then need to maintain; we’re essentially defining our own specification here. Is this specified somewhere already that we can just link to?

  2. What happens when we want to add a new feature that’s not specified, like string interpolation? We just update this spec? Would that be a breaking change?

@GeoffreyBooth there is no direct specification for dotenv other than the documentation. i believe this is the first technical specification of it. i'd like to move with this specification. do you have any blockers?

@RedYetiDev
Copy link
Member

@RedYetiDev your comment is not really helpful or contain any actionable item. please provide direct suggestions.

Sorry! I'll do a review instead. I didn't mean for it to come off as unhelpful.

Copy link
Member

@RedYetiDev RedYetiDev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tip

I'm not a core collaborator, so these are only my suggestions (and are non-blocking)

@@ -2309,6 +2309,227 @@ import { loadEnvFile } from 'node:process';
loadEnvFile();
```

### Environment variables file parser specification
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe rename this to Environment Variable File Parsing Specification, or something similar?

IMO the same should use a -ing word

@@ -2309,6 +2309,227 @@ import { loadEnvFile } from 'node:process';
loadEnvFile();
```

### Environment variables file parser specification

This section describes how the environment variables file parser reads a file
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly, maybe replace references to a 'environment variables file parser' to just the 'parser', as it is already noted in the title.

doc/api/process.md Outdated Show resolved Hide resolved
Additionally, [Dotenv][] package has played a significant role in popularizing
this format.

#### Basic parsing
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ignore this

doc/api/process.md Outdated Show resolved Hide resolved
doc/api/process.md Show resolved Hide resolved
#### Comments

* Lines starting with `#` are treated as comments and ignored.
* Inline comments (starting with `#` after a value) are ignored, and do not
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC these are not inline comments, they are just comments

"A normal" // comment
"An inline" /* comment */ "can have more values afterward"

doc/api/process.md Show resolved Hide resolved
@IlyasShabi
Copy link
Contributor Author

@anonrig IMO this PR is ready to land

Copy link
Member

@RedYetiDev RedYetiDev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few nitpicks, but otherwise LGTM

(I'm not a core collaborator, so this is non-blocking)

@@ -2309,6 +2309,227 @@ import { loadEnvFile } from 'node:process';
loadEnvFile();
```

### Environment variables file parsing specification

This section describes how the environment variables file parsing reads a file
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"parsing reads a file" might sound better as "parser reads files" IMO

While `.env` files descend from shell scripts that export environment
variables, there are important distinctions in how they handle quoting,
spacing, and escaping values.
Additionally, the [Dotenv][] package has played a significant role in
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make sure that single spaces are used between words.


#### Basic parsing

* The parser reads line by line, splitting each line into a key and a value
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe say "key/value pair"

@anonrig
Copy link
Member

anonrig commented Jun 9, 2024

hey @IlyasShabi can you apply/address the reviews?

@@ -2309,6 +2309,227 @@ import { loadEnvFile } from 'node:process';
loadEnvFile();
```

### Environment variables file parsing specification

This section describes how the environment variables file parsing reads a file
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This section describes how the environment variables file parsing reads a file
This section describes how environment variables file parser reads a file


#### Basic parsing

* The parser reads line by line, splitting each line into a key and a value
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The parser does not read line by line. It assumes it is a valid line until a newline character is seen.


* Lines starting with `#` are treated as comments and ignored.
* Inline comments (starting with `#` after a value) are ignored, and do not
affect parsing of the value.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
affect parsing of the value.
effect the parsed value.


#### Empty values

* Variables with no value assigned (just a key followed by `=`) are set to
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Variables with no value assigned (just a key followed by `=`) are set to
* Variables with no value assigned (for example, a key followed by `=`) are set to

#### Multiline values

* Values enclosed in quotes described above that span multiple
lines are accepted and stored with newline characters.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
lines are accepted and stored with newline characters.
lines are considered valid and includes escaped new line characters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc Issues and PRs related to the documentations. process Issues and PRs related to the process subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants