Opened 5 years ago
Closed 5 years ago
#45187 closed defect (bug) (fixed)
Dependencies from NPM packages do not have version passed when registered
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 5.0 | Priority: | normal |
Severity: | normal | Version: | 5.0 |
Component: | Script Loader | Keywords: | fixed-5.0 |
Focuses: | Cc: |
Description
For WordPress 5.0, new scripts and styles were added in #45065 that are developed externally and distributed through NPM packages. They are either developed through Gutenberg project, or fully independent from WordPress (registered in wp_default_packages_vendor()
function).
In all cases, when those dependencies are registered to be used in WordPress, versions of their respective packages are not passed.
There are two ways to solve this. Either by switching to associative arrays so that instead of
'react-dom' => array( 'react' ),
we have
'react-dom' => array(
'dependencies' => array( 'react' ),
'version' => '16.5.2',
),
or by ditching arrays and using approach already used in wp_default_scripts()
and wp_default_styles()
.
Attachments (2)
Change History (10)
This ticket was mentioned in Slack in #core by netweb. View the logs.
5 years ago
#4
@
5 years ago
I'm working on a bit different part of the process related to that, to find a way for updating dependencies of packages. I opened PR in Gutenberg which would allow to make it as easy as copy and paste to keep those lists in sync: https://github.com/WordPress/gutenberg/pull/11637.
The very last step (definitely a separate PR) would be to generate this PHP array with dependencies using some automated tooling so we didn't have to maintain it manually anymore. We are not quite there as we still have some WordPress core dependencies listed which aren't published to this repository and there not published to npm.
#6
@
5 years ago
- Owner set to youknowriad
- Resolution set to fixed
- Status changed from new to closed
In 43925:
I've started to go down the rabbit-hole of adding individual versions to these, and although it's not that hard to pragmatically update these, I'm not entirely sure it's actually going to be needed.
Currently
$wp_version
will be used as the version string, which for WordPress-sourced scripts is enough.External libraries (ie. not the
@wordpress/*
npm packages) could do with the version number to be standardised with the rest of the external libraries and It's also a great way to find out which version is actually committed to core at any given time.I've uploaded 45187.diff which converts it to individual
$script->add()
calls with their versions, and a very rough proof-of-concept PHP which updates thescript-loader.php
versions with that frompackage.json
.(Try to ignore the fact the dependancies are much more unreadable now, some whitespace and multi-line registration could fix that, i just took the shortcut for a POC)