CodexModule::processStyle() looks at the path of the style file to
detect whether it's an already-flipped Codex file. In
I11c6a81a1ba34fe10f4b1c98bf76f0db40c1ce98 we broke this logic so that it
was comparing a full path (prefixed with MW_INSTALL_PATH) to a relative
path (not prefixed), so the detection always failed and we'd flip every
file. For Codex files, this meant we double-flipped the RTL files back
to LTR.
Follow-Up: I11c6a81a1ba34fe10f4b1c98bf76f0db40c1ce98
Bug: T373676
Change-Id: I49f14dcc503a3279362559197f12b2852276fb5e
We were only showing the development mode warning when Codex was used in
code splitting mode, but not when the full library was being loaded.
Bug: T314507
Change-Id: I22e9707b659b004ef1059f8b13feaf3f61b7ca28
Developers can use this to test their local version of Codex with
MediaWiki by pointing $wgCodexDevelopmentDir to their local clone of the
Codex repo, e.g. $wgCodexDevelopmentDir = '/home/yourname/git/codex';
Setting $wgCodexDevelopmentDir affects where the following things come
from:
- Codex JS/CSS files for the full library
- Codex JS/CSS files for code-split chunks, and the manifest.json file
that points to them
- Icons retrieved by CodexModule::getIcons()
- CSS-only icons imported in Less
- Design tokens imported in Less
Other changes in this patch:
- Add CodexModule::makeFilePath() to centralize the repeated path
concatenation. This makes it easier to switch out the regular path for
the dev mode path.
- Replace all uses of $IP (which is deprecated) and MW_INSTALL_PATH in
CodexModule with the BaseDirectory config setting.
- Make CodexModule::getIcons() reset its static cache if the path to the
icons file changes. Without this, it's impossible to make the unit
tests pass.
- Move the i18n messages code from the CodexModule constructor to
getMessages(). It can't be in the constructor because makeFilePath()
doesn't work there (it fails because the Config object hasn't been set
up yet).
- Add a 'mediawiki.skin.codex' import path so that we can stop
hard-coding the path to the Codex mixins file. Without this, we can't
make the Codex mixins come from the right place in development mode.
- Consider $wgCodexDevelopmentDir in setting the cache key for compiled
Less code, since changing this setting can change the output of Less
compilation (by changing design tokens, icons or mixins).
- Add unit tests for (the non-dev mode behavior of)
CodexModule::getIcons() and the i18n message key handling.
Bug: T314507
Change-Id: I11c6a81a1ba34fe10f4b1c98bf76f0db40c1ce98
Previously, ResourceLoader's CodexModule class was using a hard-coded
list of message keys to add to the payload any time Codex components
get used. But now we can get the list of messages directly from
Codex. This change replaces the hardcoded list of strings with
a call to file_get_contents().
The list of messages is defined in a file called "messageKeys.json"
in the Codex package. In the next release of Codex, this file will
be pulled in via foreign-resources.yml; for now it has been added
manually to the Codex files in resources/lib.
Bug: T371330
Change-Id: Ib7ca66d67153dfba72d8d49b0181d49b007eedce
Codex 1.11.0 introduces a number of new message keys. These messages
should all be defined within MediaWiki's i18n system in advance of
the introduction of Codex 1.11.0 to MW Core.
In the future this process will be streamlined according to the
pland described in https://phabricator.wikimedia.org/T371330.
Bug: T371628
Change-Id: I038fe6a8fd02614a60aa8912796384ba986b4ca4
In particular, this allows the `codex-styles` module (or really any
module with `codexStyleOnly` set to true) to be loaded as a style-only
module via addModuleStyles.
Bug: T369812
Change-Id: I5b58c577e0279331de4471a1a40dbb08624fb7e5
- In Vue.createMwApp, provide `mw.msg` as the CdxI18nFunction,
which will be used inside Codex components to get translated
messages for certain strings
- Include Codex messages in CodexModules that use Vue components
- Add the codex i18n dir to the LocalisationCache message dirs
and to the banana config in the Gruntfile
Bug: T368449
Change-Id: I24477f5f6dcb34ad1c0959d60cdf221e859db5ce
CODEX_MODULE_DIR is always the /modules subdirectory of
CODEX_LIBRARY_DIR, so remove it and derive it that way instead.
- Update tests accordingly
- Rename test data files accordingly
- Use CODEX_LIBRARY_DIR in one place where we had neglected to use a
constant
Change-Id: Ieb347c2d128f3addfb11f6aca79d63969434f342
We had disabled style flipping entirely for CodexModules, but that's
wrong. The styles from Codex added by CodexModule itself shouldn't be
flipped, but the styles listed in the 'styles' property of the module
definition should be flipped.
To make this work correctly, change CodexModule to:
- No longer override getFlip(), so that non-Codex styles are flipped
correctly
- Override processStyle() to bypass style processing (which includes
flipping) for Codex style files
- Add a CODEX_LIBRARY_DIR constant, so that we can detect style files
from both addComponentFiles() and loadFullCodexLibrary() based on
a path prefix
Bug: T363205
Change-Id: I60f4b779ffbd559437e89ba36885479447f1db3c
Previously we provided an alternate build of Codex styles under
the name "theme-wikimedia-ui-legacy" with some different values
for size/font-size. We have removed all distinctions between
legacy and non-legacy builds of Codex upstream, so this change
updates CodexModule.php on MediaWiki to stop serving the
"legacy"-specific Codex files when they are requested. Instead,
the default Codex files will be provided instead.
In the future these code paths can be removed entirely; for now
this can stay for backwards compatibility.
Bug: T360806
Change-Id: Ic114e284d34cc9ea29701085ed766484cbeea3e8
For now, the "experimental" case is still handled, it
just returns the normal Codex files.
Bug: T363006
Change-Id: I70764969deeebc52a734ce4078bf1e4edb0cc23b
FileModule::supportsURLLoading() looks like it should return false for
CodexModules since they have packageFiles, but it runs before we can add
things to $this->packageFiles (at least for modules without packageFiles
of their own, like @wikimedia/codex-search). We can't call setupCodex()
and then call the parent method like we do for other overridden methods,
because we don't get a Context object, so just always disable URL
loading.
Not doing this led to a bug where the output of the
@wikimedia/codex-search module was empty when ?debug=1 was passed,
because we erroneously marked that module as supporting URL loading when
in reality it contained package files.
Bug: T358903
Change-Id: I7b87f78ed901b79236c8280a08bb73ac813926c7
This is still experimental and not necessarily stable, but adding this
for now so that skins can experiment with it.
A skin can select this theme by setting the SkinCodexThemes entry for
its skin to "experimental".
Also rework CodexModule::getManifestFilePath() to be array-based, now
that we have more than two themes to handle there.
Bug: T356542
Change-Id: I6791d4d8c6686845181af7bc79f6eecc1e601add
This patch provides a way to load the entire Codex library in
CodexModule. This is needed when a user wants to load the
entire Codex library versus a subset module that uses
treeshaking.
- Added a new method and option to load the full Codex library
- Converted the module definitions of @wikimedia/codex and
codex-styles. The `@wikimedia/codex` module loads the entire
Codex library in CodexModule and does not utilize the manifest
files. We removed the themeStyles map from the `codex-style`
module definition; and added a themeStyle map in the CodexModule
to ensure that styles are loaded based on the specified theme
and direction.
Bug: T355840
Change-Id: I3b4158171c69427cdcb7c705712bfd55cde81d42
Normalize $options['dependencies'] to always be an array. This makes the
code below simpler, and also more resilient (as written, it would have
errored if $options['dependencies'] was a string, which is valid usage).
Follow-Up: I656061bb0ef95b207241423a6d8c25a1448b6f24
Change-Id: I58389fa2bdf450102899b17fe56a6b38794178da
- Add a getCodexFiles() method that parses the manifest and transforms
it to a more useful format based on actual file names rather than
manifest keys
- Cache the result as a static class property, so that it's reused
between all CodexModule instances
- Use the resulting data structure to simplify the rest of the code
- This also has the side effect of correctly throwing an error when a
nonexistent file is requested (this wasn't the case before). Add a
test case for this.
- Add a test for this new method in CodexModuleTest.php
Change-Id: Id527cef0e19fec7b54af3bf65a1de66f50d5fff0
Instead of using an awkward current( array_filter( ... ) ) construct to
find back the file name of each component, keep track of the component
name -> file name mapping in an associative array as we find files in
the manifest before the dependency resolution stage, and then reuse that
map when we build the exports object later.
Change-Id: Ie16a27ae039c758e508c11b78d088006c9d8083d
CodexModule throws an InvalidArgumentException if one of the elements
of the codexComponents array refers to a private chunk rather than a
public entry point file. Add a unit test asserting this behavior.
Also add an `isset()` to the check in CodexModule so that it doesn't
cause a PHP notice about a missing array index.
Bug: T353191
Change-Id: I3e31511aeeb42d825c308f047894f5eba28b0f27
CodexModule always returns different style files for LTR vs RTL (e.g.
CdxButton.css vs CdxButton-rtl.css), so we don't want CSSJanus to flip
them. That results in double-flipping, breaking RTL support.
Change-Id: I13c78b3d1c6e53b025887a6ab2d7baf42c053310
As of Codex 1.3.0, CJS files emitted from the library build process
will have a .cjs extension instead of a .js extension (per Vite's
library mode behavior when working with ESM codebases).
This change updates the CodexModule code to be file-extension agnostic;
.mjs, .cjs. and .js file extensions are all considered valid now.
Change-Id: Iccb53b4c01daf90d23476f24e50066adb41685dd
If a generated chunk is listed in the codexComponents array,
an exception will be thrown informing the developer that the
item is not an export of Codex and cannot be required.
Text fixtures and expected values were updated to match
recent changes to the manifest that made composables
explict entries.
Bug: T353191
Change-Id: Ie3e35501993b1ad5d29ebecbcc8203e7f4ea8c81
This patch handles the scenario of an empty codexComponents array in the
module definition file with a descriptive error message that allows
developers to recover from the situation.
The scenario of codexComponents being omitted entirely is not handled
since there is a way to use this module only for its themeStyles feature
that does not require definition of codexComponents.
Bug: T353187
Change-Id: I65ad8dc338f5e570e93d7918b053b953755c12d5
This patch adds a runtime check to identify when a Codex component is imported without first being defined in the `codexComponents` array of the module definition file.
The currently shown warnings or errors are not consistent between components and are confusing since they occur at different points in the code paths of each component.
The proposed change throws a custom error message mentioning the component missing from the module definition. The location of the component's `require` call can also be inferred from the stack trace.
Bug: T353187
Change-Id: Iee8e3b0769c10407ce08de35ba38e8e5a804d6c9
For CodexModules that are not style-only and use the
codexComponents option, Vue is required and failing to include it
as a dependency currently breaks things. This patch adds Vue as
a dependency of such a CodexModule to prevent errors.
Bug: T352724
Change-Id: I9132f56eebfd46a1f287cfb1febd2670975a0985
This requires the path to the Codex modules directory
to be configurable, so we can use static manifest and
component files in tests. This is achieved by changing
the constant storing the Codex modules dir from private
to protected so it can be overridden when creating a
test module.
Bug: T350054
Change-Id: Icd3c6c5d2a82f5a5fb1c38b52e54893034e7375c
* Introduces support for tree-shaking in CodexModule. A limited
subset of the library can be returned if the "codexComponents"
option is provided.
* Additional options for script-only and style-only subsets have
also been added: "codexScriptOnly" and "codexStyleOnly",
respectively.
* Reorganizes the PHP code for more clarity.
Co-authored-by: Roan Kattouw <catrope@wikimedia.org>
Co-authored-by: Anne Tomasevich <atomasevich@wikimedia.org>
Bug: T350054
Change-Id: Iadba806167abaa4996fd05d4ede909d737251901
This patch removes styles from the `@wikimedia/codex` and
`@wikimedia/codex-search` modules, and moves them into new,
separate modules. This will enable use of CSS-only Codex
components within MediaWiki.
Additionally, this patch adds a check for theme styles in the
CodexModules class to prevent it from breaking if they're
not provided.
Bug: T330466
Change-Id: I259a706641fcd51787d7492e7ada11db78277659
Add a "SkinCodexThemes" key to skin.json, that works just like
"SkinOOUIThemes". Based on the value the skin sets,
ResourceLoader\CodexModule loads the correct Codex theme for the skin.
The default theme is wikimedia-ui, meant for skins with a 16px base font
size. Skins with a 14px base font size (like Vector) should override
this to use wikimedia-ui-legacy.
Bug: T324367
Change-Id: I7435413928f2b8c5d43c34d9e2e7df470d710c93
Move ResourceLoader classes to their own namespace. Strip the
"ResourceLoader" prefix from all except ResourceLoader itself.
Move the tests by analogy.
I used a namespace alias "RL" in some callers since RL\Module is less
ambiguous at the call site than just "Module".
I did not address DependencyStore which continues to have a non-standard
location and namespace.
Revert of a241d83e0a.
Bug: T308718
Change-Id: Id08a220e1d6085e2b33f3f6c9d0e3935a4204659
This reverts commit e08ea8ccb9.
Reason for revert: Breaks Phan in extensions, and as far as I’m aware,
this change isn’t urgently needed for anything, so the simplest fix is
to revert it again for now. After PHP 7.4 it should be safer to try this
again (we hopefully won’t need the two “hack” classes by then).
Bug: T308443
Change-Id: Iff3318cbf97a67f821f78e60da62a583f63e389e
Move ResourceLoader classes to their own namespace. Strip the
"ResourceLoader" prefix from all except ResourceLoader and
ResourceLoaderContext.
Move the tests by analogy.
I used a namespace alias "RL" in some callers since RL\Module is less
ambiguous at the call site than just "Module".
I did not address DependencyStore which continues to have a non-standard
location and namespace.
Change-Id: I92998ae6a82e0b935c13e02a183e7c324fa410a3
2022-05-16 14:41:27 +10:00
Renamed from includes/resourceloader/ResourceLoaderCodexModule.php (Browse further)
