Add deprecation/bc support for library-overrides when files are moved

Got something working.

The main drawback is that the deprecation message doesn't include the deprecated in /removed in versions, but I just cannot think of a way to both get that and have a useful message. Since this is supposed to be an internal API anyway, maybe we can skip that. Or if someone has an idea for the format + message that's better and will actually work, that's great please tell me.

Hoping to get a nice deprecation failure on a test somewhere so we can just add more expectDeprecation() rather than a whole new test case.

Updated the issue summary a bit. Will need docs and change record but would like reviews before that in case the format ends up changing.

Deprecation support is in with test coverage now.

The one limitation of the deprecation support is you can only have one version/change record per library that you've moved files from - however moving multiple files to and from the same libraries in different releases seems like an extreme edge case. If you move multiple files from the same library (like system/base) to lots of different libraries in different versions, it will support that fine because it's the libraries you move files to that determine the messages.

moved_to:
  version: VERSION
  css:
    base:
      css/base-remove.css: {}
  js:
    js/foo.js: {}
  moved_files:
    theme_test/moved_from:
      deprecation_version: drupal:X.0.0
      removed_version: drupal:Y.0.0
      deprecation_link: https://example.com
      css:
        base:
          css/foo.css:
            base: 'css/base-remove.css'
      js:
        js/bar.js: 'js/foo.js'

So not sure I fully follow

"moved_to" is the new library
Then are we saying we are moving files from "theme_test/moved_from"

Should the deprecation links be on "theme_test/moved_from" though? The deprecated key makes it sound like we are removing these files from the library.

But moving to NW for the change record as that might help clear it up.

Should the deprecation links be on "theme_test/moved_from" though? The deprecated key makes it sound like we are removing these files from the library.

We only get library info for libraries that are requested during the request, when 'moved_from' is requested (if that ever happens), it doesn't matter that some code used to override a file in it, because the file is no longer there to be overridden.

However when the 'moved_to' library is requested, that includes the file that the theme is trying to override - so we need to warn the theme then.

Filled out the change record a bit.

Thanks, reading the CR and that does help clear things up.

I left some comments in the MR.

Reworked the deprecation messages, I was trying to keep the maximum amount of information, but having them readable by a human is more important.

Does the CR need to be updated with new message?

No the wording isn't in the change record.

Gotcha!

Added the moved_files entries on 📌 Move system/base component CSS to respective libraries where they exist Fixed .

@catch, thanks for adjusting the deprecation message.

There were conflicts so I did a rebase. There was one conflict in LibraryDiscoveryParser in the use statements. It was a simple fix so I leaving this at RTBC.

nod_ → closed merge request !7132

Committed 5254c77 and pushed to 11.x. Thanks!

Backported to 10.3.x

Automatically closed - issue fixed for 2 weeks with no activity.