-
Notifications
You must be signed in to change notification settings - Fork 28
fix(scripts): rename script from test-unit
to test-unit-js
#86
Conversation
@@ -30,11 +30,11 @@ This is how you execute those scripts using the presented setup: | |||
|
|||
## Available Scripts | |||
|
|||
### `wp-scripts test-unit` | |||
### `wp-scripts test-unit-js` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should swap the title and alias :)
I'm wondering if you can use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code LGTM, thanks for tackling the follow-up PR 👍
I'm wondering if we should put the summary of what you described in this PR in a README file that would live in the repository, so we could refer to it when discussing further PRs. What do you think?
Can someone explain why we use Why not Why not in these example configurations Can't we just pick one and stick with it? Conventionally I've seen this as |
The 3 config options I listed above are examples of how an external repo may use the scripts in their For example from cfg 2. above: The external repo task names on the left use the {
"scripts": {
"test-unit:js": "wp-scripts test-unit-js",
"test-unit:php": "wp-scripts test-unit-php",
"test": "npm-run-all test-unit:*",
},
} The above could also be rewritten as: {
"scripts": {
"test:js": "wp-scripts test-unit-js",
"test:php": "wp-scripts test-unit-php",
"test": "npm-run-all test:*",
},
} Or rewritten as: {
"scripts": {
"foo": "wp-scripts test-unit-js",
"bar": "wp-scripts test-unit-php",
"test": "npm-run-all foo bar",
},
} The npm-run-all package has a somewhat widespread usage nomenclature using the {
"scripts": {
"sometask:1": "abc",
"sometask:2": "def",
"sometask:3": "ghi",
"sometask:4": "xyz",
"task": "npm-run-all sometask:*",
},
} The result is that running in |
Yes, we use only I think we can leave it as it is and continue using |
Follow up to #83
This PR seeks to update and change the default script name from
test-unit
totest-unit-js
The goal behind this to facilitate what was discussed in #83 (comment) where a configuration for WordPress Core can use
test-unit
as a catch all task for not just JavaScript tasks, e.g:Originally a configuration of was suggested:
The proposed solution in this PR would then allow for more semantic naming of the tasks that could then facilitate the following flexible configurations:
Cfg 1: This option is quite verbose in listing each of the available
test-unit-*
scripts available, it then usesnpm-run-all
scripts to group the scripts by language, and finally anothernpm-run-all
script to group those together.Cfg 2: This configuration is nowhere near as verbose as Cfg 1, a couple of
test-unit-*
language scripts then grouped together by a singlenpm-run-all
task.Cfg 3: Lastly, the simplest of each config option, a single stand-alone
test-unit
task.Each of the above script names above includes semantic meaning in their naming when reading the script name each name clearly describes itself.
Each of these script names clearly describes itself
•
test-unit-qunit
•
test-unit-jest
•
test-unit-wordhat
•
test-unit-phpunit
•
test-unit-js
•
test-unit-php
Without this PR the script name
test-unit
is quite generic, there is no way to know without looking at the code that this is a JavaScript only script, in fact not even that, its an alias oftest-unit-jest
Switching
test-unit
totest-unit-js
allows us to usetest-unit
as a higher level alias, it can then be used to call bothtest-unit-qunit
andtest-unit-jest
if both Qunit and Jest tests are detected in the target repo, likewise PHP tasks, if PHPUnit tests are detected it can also include those.