Split item-list.module.css out to its own library

Created on 11 March 2025, 29 days ago

Problem/Motivation

Split from πŸ“Œ Refactor system/base library Needs work

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

πŸ“Œ Task
Status

Active

Version

11.0 πŸ”₯

Component

CSS

Created by

πŸ‡¬πŸ‡§United Kingdom catch

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @catch
  • πŸ‡¬πŸ‡§United Kingdom catch

    CSS is added on https://drupal-dev.ddev.site/admin/reports/fields but doesn't actually work, maybe a weight issue?

  • Merge request !11444move item-list.module.css to its own library. β†’ (Open) created by catch
  • πŸ‡¬πŸ‡§United Kingdom catch

    Found the problem - claro wants to extend, not override, the library.

  • First commit to issue fork.
  • Pipeline finished with Failed
    23 days ago
    Total: 716s
    #450536
  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Fixed a merge conflict but seems performance tests are failing.

  • Pipeline finished with Failed
    23 days ago
    Total: 2282s
    #450564
  • πŸ‡¬πŸ‡§United Kingdom catch

    Updated the performance tests, but the new layout builder failures are consistent so something is going on here.

  • πŸ‡¬πŸ‡§United Kingdom catch

    Should be green now. Looked like very complicated issues in LayoutBuilderUITest but was in fact a typo in the starterkit theme library definition.

  • πŸ‡§πŸ‡ͺBelgium borisson_ Mechelen, πŸ‡§πŸ‡ͺ

    It is green now, and we're decreasing the page weight, that's great.
    I am not sure about moving the file though, people are not supposed to reference the file by path, but it seems like it increases the likelihood this will be a breaking change?

  • πŸ‡¬πŸ‡§United Kingdom catch

    @borisson_ the moved_files definition supports libraries_override explicitly - it transparently switches the override and triggers a deprecation error. That leaves two situations:

    1. Someone modifying the file in hook_library_info_alter() - but data structures passed to alter hooks are excluded from backwards compatibility for this reason, we'd have the same problem changing the location in a major release too.

    2. Someone directly referencing the file in a separate library definition, this feels very, very unlikely because until this MR it was loaded on every request anyway, so it would result in double-loading.

    We've also had πŸ“Œ Move system/base component CSS to respective libraries where they exist Fixed in core since around 10.2 or 10.3, and not had any regressions reported that I'm aware of (this is one of many follow-ups to that issue to try to finish the meta).

  • πŸ‡§πŸ‡ͺBelgium borisson_ Mechelen, πŸ‡§πŸ‡ͺ

    Thanks for that information. Moving to rtbc based on #10.

  • The Needs Review Queue Bot β†’ tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

    This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

    Consult the Drupal Contributor Guide β†’ to find step-by-step guides for working with issues.

  • First commit to issue fork.
  • Pipeline finished with Success
    7 days ago
    Total: 464s
    #464032
  • πŸ‡ΊπŸ‡ΈUnited States dcam

    Rebased

Production build 0.71.5 2024