[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