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

WordPress Trac noreply at wordpress.org
Fri Jul 26 10:21:27 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 mcsf):

 Replying to [comment:10 pento]:

 Thanks for the detailed answer. My issue was the wrong assumption that the
 script split was an attempt to retain the possibility of invoking NPM
 scripts with custom environment variables, e.g. `FOO=bar npm run test-
 next`, hence my silly counterexample.

 > 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:

 This is quite tricky. (Is it OK if I have a deep longing for Makefiles?)

 Given the circumstances, I don't strongly oppose to the `-next` auxiliary
 scripts. I was going to suggest we use `dotenv` directly within Node
 script files. For example:

 {{{
 require('dotenv').config();
 const url = `http://localhost:${process.env.LOCAL_PORT}`;
 }}}

 … but the reality is that many of the package-defined scripts are just
 inline arrangements of other scripts, so this would require adding a bunch
 of Node files just to run them. Which isn't wrong, just cumbersome.

 For kicks, I played with the following:

 {{{
 $ cat if-def
 #!/usr/bin/env node

 const variables = process.argv.slice(2);

 for (const variable of variables) {
         if (process.env[variable] === undefined) {
                 process.exit(1);
         }
 }

 process.exit(0);
 }}}

 {{{
   "scripts": {
     "hello": "./if-def NAME && echo \"Hi, $NAME\" || dotenv npm run hello"
   },
 }}}

 {{{
 $ npm run hello

 > npmtests at 1.0.0 hello /private/tmp/npmtests
 > ./if-def NAME && echo "Hi, $NAME" || dotenv npm run hello


 > npmtests at 1.0.0 hello /private/tmp/npmtests
 > ./if-def NAME && echo "Hi, $NAME" || dotenv npm run hello

 Hi, User
 }}}

 Is this horrible? Yes. Let's not do this ever. But it speaks to how NPM is
 ill-equipped for supporting this sort of customisable flow.

 **Moving past this,** let's say that `-next` is fine for now. I'll review
 other pieces of the patch. :)

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


More information about the wp-trac mailing list