-
Notifications
You must be signed in to change notification settings - Fork 4
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
Introduce register_asset() and enqueue_asset() functions; refactor & test plugin #22
Conversation
// If we fail to match a .css asset, try again with .js in case there is a | ||
// JS wrapper for that asset available (e.g. when using DevServer). | ||
if ( empty( $asset_uri ) && is_css( $target_asset ) ) { | ||
$asset_uri = Manifest\get_manifest_resource( $manifest_path, preg_replace( '/\.css$/', '.js', $target_asset ) ); |
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.
This is the piece of this that I'm least confidant about: it solves #1 because you can say
register_asset( $manifest_path, 'some-file.css', [ 'handle' => 'my-css' ] );
but it's potentially unintuitive that this could lead to the enqueuing of a JS file in some circumstances.
There's also a small but non-zero chance that, in the event that you try to enqueue a CSS file while running the dev server, and you wish to enqueue the CSS in a different context or condition than the JS file from which the CSS will be extracted, that you could end up having the JS run in an unexpected situation if you try to enqueue the CSS without the JS (impossible when they haven't been split apart using MiniCSSExtractPlugin). I cannot think off hand of a time when this would practically happen on a project, but as much as moving away from autoenqueue
distances us from the ✨ magic ✨ of this library, the inference of a JS file when you asked for CSS still is "magic" and may be confusing.
Or, am I over-thinking this 😁
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.
This has tricky implications for dependency handling. We may need to revert to the scripts
and styles
arrays for dependencies rather than tracking it as one bundle, or else reinstate some of the $has_css
logic from the prior versions of this function.
The logic of this function is not directly related to the logic we want to test, so mock it globally.
Webpack contenthash strings can be 20 characters when using Webpack defaults, which would not be long enough to trigger our full hashing heuristic. Since the average word length in most widespread languages across the globe is less than 15, and long words are rarely restricted to only a-f, our adapted heuristic should still be robust enough to catch hashed filenames with very limited false positives.
@mikeselander (and @tfrommen, because I'm sure there's a better way to handle the testing for registered scripts!), would love your eyes on this if you would be so kind! The last missing piece of functionality is that enqueueing a CSS file in a dev server environment does not work the same as registering such an asset. I want to dig on on that but I may like to get this landed and fix that bug separately, because this has gotten somewhat ambitious. |
composer.json
Outdated
}, | ||
"scripts": { | ||
"lint": "phpcs --standard=phpcs.ruleset.xml ." | ||
"lint": "phpcs --standard=phpcs.ruleset.xml .", |
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.
Why is PHP_CodeSniffer
expected as global dependency? Why is PHPUnit a local one (which I absolutely prefer)?
Since the config file has a default name, it will automagically get picked up. No need to specify:
"lint": "phpcs --standard=phpcs.ruleset.xml .", | |
"lint": "phpcs .", |
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.
This is not the same for me. If I do not manually specify the ruleset, it uses a completely different set of standards. Am I possibly using an invalid ruleset name?
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.
Ah, right. Sorry, my bad. The supported name would be phpcs.xml(.dist)
. (Or others.)
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.
Ahah! Thanks!
phpcs.ruleset.xml
Outdated
<rule ref="vendor/humanmade/coding-standards"> | ||
<exclude name="Squiz.Commenting.FunctionComment.ParamCommentFullStop" /> | ||
</rule> | ||
<rule ref="vendor/humanmade/coding-standards"> |
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.
Reference the standard by name, not path:
<rule ref="vendor/humanmade/coding-standards"> | |
<rule ref="HM"> |
public $enqueued; | ||
|
||
public function __construct() { | ||
$this->reset(); |
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.
Why would you need to reset something on construction? Do you mis-use __construct
somewhere in your code?
If not, I'd provide default values for the two properties/fields (and make them (private
), and delete the constructor.
*/ | ||
public function test_maybe_setup_ssl_cert_error_handling( bool $is_admin, string $script_uri, bool $expect_action, string $message ) : void { | ||
WP_Mock::userFunction( 'is_admin' )->andReturn( $is_admin ); | ||
if ( $expect_action ) { |
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.
This is one of the examples where Brain Monkey provides some more useful helpers. It stubs the has_action
function (using a fake registry), so your code here could be as simple as this:
$this->assertSame( $should_have_added_action, has_action( ... ) );
No need for a conditional and/or two different functions to check what you're interested in.
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.
That sounds really appealing; swapping mock library's out of scope right now, but i'll look into it for later on@
Co-authored-by: Thorsten Frommen <[email protected]>
Co-authored-by: Thorsten Frommen <[email protected]>
Co-authored-by: Thorsten Frommen <[email protected]>
Co-authored-by: Thorsten Frommen <[email protected]>
Co-authored-by: Thorsten Frommen <[email protected]>
Co-authored-by: Thorsten Frommen <[email protected]>
This PR proposes a new API for inclusion in v0.4, oriented around a more WordPress-style (see #21) single-asset function signature of
This PR simultaneously (sorry!) introduces some refactoring and renaming of existing internal methods, and adds a number of unit tests across the project.
Needs testing and additional tests prior to 0.4, but this is now available for review & critique.
Tagging @svandragt @johnbillion and @mikeselander as thanks for your constructive criticism on other issues; let me know what you think!