Created MR !155 with the fix described in the proposed resolution in the issue summary. Replaced returning an exception object in the default case of the match expression with resuming the fiber instead. From my testing, it resolves the problem and doesn't affect other functionality.
Pushed changes including refactoring to a generator function and added replies to all comments.
@phenaproxima Progress bar and option to export all content entities removed.
Created MR !13309 with following changes:
- added option to export all content entities of a given type
php core/scripts/drupal content:export entity_type_id --dir=...--diroption is required- if
--with-dependenciesoption is provided, then also exports dependencies - for example
php core/scripts/drupal content:export node --dir=./content
- added option to export all content entities of given type filtered by a bundle
php core/scripts/drupal content:export entity_type_id --bundle=entity_bundle_id --dir=...- entity_type_id argument is required
--diroption is required- if
--with-dependenciesoption is provided, then also exports dependencies - for example
php core/scripts/drupal content:export node --bundle=article --dir=./content
- added option to export all content entities
php core/scripts/drupal content:export --dir=...--diroption is required--with-dependenciesoption is ignored- for example
php core/scripts/drupal content:export --dir=./content
- when exporting multiple entities, progress bars are shown, one per exported entity type
- when verbose output option is used (
--verboseor its shortcuts), instead of the progress bar, information about each exported entity is shown - added some additional test cases for new export options
Updated the MR !95 to use tailwindcss-in-browser 0.4.0 and the new compilePartialCss() function it provides. It should now be ready for review.
Related pull request for tailwindcss-in-browser https://github.com/balintbrews/tailwindcss-in-browser/pull/17 that also fixes the error reported in this issue.
It adds support for importing base Tailwind styles so they can be loaded using standard Tailwind css layers to improve compatibility between code components and Drupal themes using Tailwind.
So with these changes, when using @import "tailwindcss"; in global CSS, base Tailwind styles will be imported a second time (but then deduplicated during lightningcss transform).
Created draft MR !95 that adds support for using @apply directives with Tailwind classes in component CSS.
It depends on https://github.com/balintbrews/tailwindcss-in-browser/pull/18, so for now in the draft MR tailwindcss-in-browser is pinned to temporary feature branch with changes from the linked pull request.
Created MR !2 that replaces the custom pager with the core one and uses entity query instead of raw query to fetch filtered paragraph types. This fixes errors described in the issue summary.
Reverted the last commit that broke the functionality and pushed small fixes for issues reported by phpstan.
I'm already using changes from the MR on a few work projects, and it works fine.
Since reinfate and mh_nichts also reported that the changes work for them, I think we can merge this.
And maybe as a follow-up in a separate issue, work on adding some examples to the docs to make it easier to start using functionality added in this issue and the module in general.
@reinfate
Tests and fix for @vite/client look good. Thanks.
@darvanen
An example configuration with ViteJS setup in the project root for compiling assets in custom themes and modules could look like this:
composer.json
vite.config.js
web/
index.php
core/
themes/
contrib/
custom/
modules/
contrib/
custom/
my_module/
my_module.info.yml
my_module.libraries.yml
assets/
my_module.css
my_module.js
libraries/
dist/
.vite/manifest.json
assets/
my_module-G0XxVM1l.css
my_module-BbupU5xU.js
...
Configure ViteJS
In vite.config.js:
import { globSync } from "tinyglobby";
import { defineConfig } from "vite";
const entrypoints = [
// Scan all .js files in custom themes and modules.
"./web/{themes,modules}/custom/**/*.js",
// Scan all .css files in custom themes and modules.
"./web/{themes,modules}/custom/**/*.css",
];
export default defineConfig({
build: {
// Generate asset manifest.
manifest: true,
// Save compiled assets and asset manifest to the web/libraries/dist/ directory.
outDir: 'web/libraries/dist',
// Configure entrypoints.
rollupOptions: {
input: globSync(entrypoints),
},
},
...
});
Configure custom themes/modules
In theme/module.info.yml:
...
vite:
// Set vite root to the parent directory of Drupal web root directory.
viteRoot: '/..'
// Set vite dist directory same as outDir option in vite config (it is resolved relative to viteRoot).
distDir: web/libraries/dist
// Enable vite support for all libraries and components.
enableInAllLibraries: true
enableInAllComponents: true
In theme/module.libraries.yml:
// Provide relative asset paths as normally, Vite module will automatically make them relative to viteRoot and depending on mode prepend vite dev server url or rewrite them based on asset manifest.
my_library:
css:
theme:
assets/my_module.css: {}
js:
assets/my_module.js: {}
How Vite module works
In this example, the Vite module will:
- check if my_module/my_library library should be managed by vite module
- for each asset in library
- trasform asset path (based on configured viteRoot and drupal web root) so it is relative to vite root
- in dev mode:
- prepend dev server url to the transformed path
- in dist mode:
- match transformed source path to the dist path based on vite asset manifest
- transform dist path so that it is relative to the module directory
The incompatibility is not only with paragraphs_selection but with any entity reference selection handler that doesn't store available paragraphs types under target_bundles key same as the default paragraph reference selection handler.
Approach from MR !111 worked well for me with custom selection handler that uses categories of paragraph types instead of paragraphs types directly.
Created MR !211 against 3.0.x branch with changes from MR !111 + dependency injection instead of \Drupal::service() and updated phpdocs.
Looks good, will tag a new release shortly.
Looks good, will tag a new release shortly.
Looks good will tag a new release shortly.
Perhaps this could be closed in favor of
✨
Add support for using vite from the root of the project
Active
?
I'm working in there on adding general support for using Vite outside the theme/module directory, including but not limited to project root. I'm still working on tests, but there's already a working implementation that can be tested.
Recent changes:
- removed use of realpath function and tests are now passing also in symlinked environment
- renamed distPath config option to distDir to more closely match Vite's build.outDir config option
Also updated IS to match the proposed resolution to the current approach and to add remaining tasks.
I will work on adding tests, but otherwise this should be ready for a review.
Looks good. Will merge and create a release shortly. For the future, if possible, please create merge requests instead of attaching patch files.
Merged and added a direct link to the section about using Drupal translations in js on the module's project page.
I'm ok with removing preload scripts for chunk imports. Removing them will fix issues we are facing right now, and if in some cases they will be needed we can always add them back with some condition/config option so they are used only when actually needed.
Added another config option `distPath` that should be set to dist directory path relative to vite root, the same as the build.outDir in vite config. The `manifest` config option is now deprecated in favor of `distPath` since vite manifest file is always in the same location in the dist directory.
Tests currently pass locally but fail in gitlab ci because of the symlinked module source. Will probably need to replace `realpath` usage when resolving paths to skip resolving symlinks.
Looks good. Merged. Will create a new release shortly.
Pushed initial implementation of the proposed solution to MR !22.
Still needs more testing, some cleanup, docs and automated test.
It adds a new `viteRoot` config option that defaults to extension directory but can be set to for example, project root. If the value starts with /, then it is resolved relative to drupal root, otherwise relative to the extension dir.
The vite root path is then used to resolve path to manifest (configured manifest path is treated as relative to vite root) and paths to assets.
For example, to use setup with vite configured in project root and dist files generated to libraries dir (web/libraries/dist) we just need to set vite root to /.. and manifest path to web/libraries/dist/.vite/manifest.json.
/vite.config.js
/web/...
/web/themes/custom/my_theme/...
/web/themes/custom/my_theme/ts/script.ts
# settings.php
$settings['vite']['viteRoot'] = '/..';
$settings['vite']['manifest'] = 'web/libraries/dist/.vite/manifest.json';
# web/themes/custom/my_theme/my_theme.info.yml
...
vite:
enableInAllLibraries: true
# web/themes/custom/my_theme/my_theme.libraries.yml
my_library:
js:
ts/script.ts: {}
As mentioned above, the problem with Drupal translations in js built by Vite is not really an issue with the module, but rather an incompatibility of Vite js minification and the way in JS translations are handled by Drupal. This will probably apply also for other modern js minification tools.
To support translations in javascript Drupal in js_alter hook scans js files from all attached asset libraries using regex looking for Drupal.t(...) and Drupal.formatPlural(...), from them extracts strings that should be translated and attaches dynamically generated script that puts available translations for found strings in the window.drupalTranslations object that is later used by translation functions.
When Vite minifies js script that is wrapped in IIFE (which is a standard Drupal practice), eg.
(function (Drupal) {
console.log(Drupal.t("test"))
})(Drupal);
then it minifies internal function parameter names since in normal circumstances it doesn't matter what names they will have, so the script becomes something like:
(function(i){console.log(i.t("test"))})(Drupal);
which functions the same but is smaller.
The problem is that Drupal to attach needed translations looks for Drupal.t which it doesn't find there so the translation for in this case 'test' isn't attached to the page.
One workaround could be to use global Drupal object directly instead of passing it as a function argument.
(function () {
console.log(Drupal.t("test"))
})();
// will be minified to
(function(){console.log(Drupal.t("test"))})();
@axioteo The plugin looks good, although it would be nice to include support for Drupal.formatPlural and make the regex a bit more elastic to catch all translation functions instances, the best would be probably to just take the beginning part of the regex Drupal uses, so something like:
[^\w]Drupal\s*\.\s*t\s*\(
// and
[^\w]Drupal\s*\.\s*formatPlural\s*\(When it comes to this issue, the best way to resolve it would be to add a section to the README that would explain the problem and suggest using the vite plugin axioteo created.
MR looks good.
Maybe a better name for the twig function would be something like `vite_get_chunk_path` it would better describe what it does and would allow adding more vite related twig functions in the future if needed.
Also before merge some documentation with usage example in the README will be needed.
Created MR from @yannickoo patch. The changes seem to work fine and fix the problem.
Will commit and release today.
Also pushed some kernel tests to the main branch that check rewritten paths in the dev and dist modes, to hopefully avoid similar problems in the future.
Code (added in
https://www.drupal.org/project/vite/issues/3448622
🐛
Asset paths for modules which names end with 'components' are rewritten incorrectly
Fixed
) for removing potential double slashes in components assets paths was replacing slashes also in https://... resulting in https:/.... which was treated as an absolute path. For some reason it didn't break when using the default localhost vite dev server url which is why it wasn't caught earlier.
Fix in https://git.drupalcode.org/project/vite/-/merge_requests/16 makes sure only double slashes at the beginning of asset paths are deduped and the dev server url is not modified.
Fixed in https://www.drupal.org/project/vite/issues/3444001 🐛 Styles imported in a chunk not being added to library RTBC which was released in 1.2.0 → .
As far as I'm aware, the current Vite version works fine with scss entrypoints.
Example:
# theme.libraries.yml
global-styling:
vite: true
css:
theme:
scss/style.scss: {}
// vite.config.js
import { defineConfig } from "vite";
import multiInput from "rollup-plugin-multi-input";
export default defineConfig(({ mode }) => {
return {
plugins: [multiInput()],
build: {
manifest: true,
rollupOptions: {
input: ["scss/**/*.scss", "!scss/**/_*.scss"],
},
},
};
});
It builds fine and produces vite manifest that is correctly handled by drupal/vite module:
// dist/.vite/manifest.json
{
...
"scss/style.scss": {
"file": "assets/scss/style-DYjrZ8Ot.css",
"src": "scss/style.scss",
"isEntry": true
},
...
}
@mvonfrie
The import multiInput from "rollup-plugin-multi-input" and then loading the plugin with multiInput.default() no longer works for me> I'm getting the following error:
You must supply options.input to rollup
Do you have at least one source file that matches paths from `build.rollupOptions.input`? I once encountered that error when trying to run build without actually having any files to build, after creating at least one, even empty, file that matches configured paths everything worked fine.
There doesn't currently seem to be a config option for that. Both hidding toolbar and linking logo to drupal.org is hardcoded.
It however can be fixed with a bit of custom code. Logo link is hardcoded in the page--mercury-editor template that can be overriden and showing admin toolbar is controlled by the `_hide_admin_toolbar` route option that can be altered → . I'm using following route subscriber to do that:
class MercuryEditorRouteSubscriber extends RouteSubscriberBase {
/**
* {@inheritdoc}
*/
protected function alterRoutes(RouteCollection $collection): void {
// Show admin navigation on Mercury Editor route.
$mercuryEditorRoute = $collection->get('mercury_editor.editor');
if ($mercuryEditorRoute !== NULL) {
$mercuryEditorRoute->setOption('_hide_admin_toolbar', FALSE);
}
}
}
It works quite well for the
new admin navigation →
(combined with changes from
https://www.drupal.org/project/mercury_editor/issues/3449328
✨
Hide new drupal admin navigation on mercury editor routes
Needs review
), not sure how it will look with other admin toolbars but it should make them show up.
Created merge request that adds support for removing the new admin navigation for the routes with the _hide_admin_toolbar option set to true, simillary to how other toolbars are removed.
With this change Mercury Editor page renders corectly without admin navigation toolbars:
Marking as RTBC. Changes from https://git.drupalcode.org/project/vite/-/merge_requests/12 worked for us in internal and client projects without any problems.
Changing to needs work as it is missing documentation of the new devDependencies option.
Change looks good. It seems that treating css as chunks worked in earlier Vite versions but was never the intended approach. https://vitejs.dev/guide/migration.html#corresponding-css-files-are-not-...
Give credit to developer who worked on the module.
Give credit to developer who worked on implementing module functionality.
Credit developers who worked on initial module implementation.