[wp-trac] [WordPress Trac] #47767: Simplify and backport the local environment

WordPress Trac noreply at wordpress.org
Fri Jul 26 00:09:45 UTC 2019


#47767: Simplify and backport the local environment
-------------------------------------+-----------------------
 Reporter:  pento                    |       Owner:  pento
     Type:  enhancement              |      Status:  assigned
 Priority:  normal                   |   Milestone:  5.3
Component:  Build/Test Tools         |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  needs-testing has-patch  |     Focuses:
-------------------------------------+-----------------------

Comment (by pento):

 You should never call the `-next` script directly, as the environment
 variable default values won't be loaded from the `.env` file.

 Given an NPM script `"test": "dotenv echo $FOO"`, a `.env` file with
 `FOO=bar`, and no `FOO` environment variable set, the following will
 happen:

 - Run `npm run test`.
 - NPM spawns a child process to execute `dotenv echo $FOO`, passing
 `process.env` (which currently doesn't have `FOO` defined).
 - The child process replaces variables with their corresponding values, so
 the command to be run is now `dotenv echo `.
 - `dotenv` runs, loads the `.env` file, and sets `FOO=bar` as an
 environment variable.
 - `dotenv` spawns a child process to execute `echo `, passing
 `process.env` (which now includes `FOO`) to the child process.
 - `echo ` is run in the child process.

 Given the same environment with a `.env` file with `FOO=bar`, no `FOO`
 environment variable set, but with two NPM scripts set, `"test": "dotenv
 npm run test-next", "test-next": "echo $FOO"`, the following will happen:

 - Run `npm run test`.
 - NPM spawns a child process to execute `dotenv npm run test-next`,
 passing `process.env` (which currently doesn't have `FOO` defined).
 - There are no variables to replace, so the command to be run is still
 `dotenv npm run test-next`.
 - `dotenv` runs, loads the `.env` file, and sets `FOO=bar` as an
 environment variable.
 - `dotenv` spawns a child process to execute `npm run test-next`, passing
 `process.env` (which now includes `FOO`) to the child process.
 - NPM spawns a child process to execute `echo $FOO`, passing `process.env`
 (which still includes `FOO`) to the child process.
 - The child process replaces variables with their corresponding values, so
 the command to be run is now `echo bar`.
 - `echo bar` is run in the child process.

 The problem that `dotenv` solves is allowing Core to set default values
 for config options, which a user can easily override, So, all of this this
 could be avoided if we had a different way to set default values for these
 environment variables. Here are some other options that I evaluated:

 - Using Bash notation to specify a default value inline. For example,
 `${LOCAL_PORT-8889}` would use `$LOCAL_PORT` if it was defined, or `8889`
 if it wasn't. There is no equivalent behaviour available when the shell is
 `cmd.exe`.
 - Use NPM config settings. For example, adding `"config": { "port": 8889
 }` to `package.json` would ensure the `$npm_package_config_port` variable
 was set to the default value of `8889` when running scripts. It can be
 overridden by running the command `npm config set WordPress:port 7778`
 before running the NPM scripts. The downside of this is that this is set
 in your `~/.npmrc` file, it isn't set on a per-project basis, so you can't
 have multiple WordPress installs running simultaneously. NPM supports a
 project `.npmrc`, which we could add to `.gitignore` to allow local
 overrides, if we weren't already using it.
 - Write a custom package that combines the magic of `dotvar`, `cross-var`,
 and `cross-env` into something that works better. This is a valid option,
 but overkill for this ticket.

 While `dotenv` has the downside of needing to have two scripts to do one
 thing, it's only a little bit of mess which can be cleaned up at a later
 date.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47767#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list