Vite plugin replacing wp package imports with deprecated namespaces?

When using acorn 5 and sage 11 with the new vite plugin, I have an existing gutenberg block with this import at the top of the file:

import {PluginDocumentSettingPanel} from '@wordpress/editor';

After loading this block into the editor, I see these warnings in the Chrome Dev Tools console:

wp.editPost.PluginSidebarMoreMenuItem is deprecated since version 6.6. Please use wp.editor.PluginSidebarMoreMenuItem instead.
wp.editPost.PluginSidebar is deprecated since version 6.6. Please use wp.editor.PluginSidebar instead.
wp.editPost.PluginPrePublishPanel is deprecated since version 6.6. Please use wp.editor.PluginPrePublishPanel instead.
wp.editPost.PluginPostPublishPanel is deprecated since version 6.6. Please use wp.editor.PluginPostPublishPanel instead.
wp.editPost.PluginDocumentSettingPanel is deprecated since version 6.6. Please use wp.editor.PluginDocumentSettingPanel instead.

I was looking at the vite plugin source, and couldn’t quite figure out what code is doing these namespace mappings. But it seems to be mapping some of these types to the editPost namespace when they were moved in more recent versions of wordpress to the editor namespace (as I specified in my import).

Not sure if this is something on my end, but it just started showing up after using the vite plugin. It could be a red herring though.

:thinking: this would generally be done by gutenberg/packages/dependency-extraction-webpack-plugin/lib/util.js at 918d152f25248a53e3fedd1ec3af2eadeb038e9d · WordPress/gutenberg · GitHub – not seeing anything related to editPost though.

Yeah you’re right. It looks like that plugin exposes a way to hook and adjust mappings like this:

const DependencyExtractionWebpackPlugin = require('@wordpress/dependency-extraction-webpack-plugin');

module.exports = {
  // ... your existing Webpack configuration
  plugins: [
    new DependencyExtractionWebpackPlugin({
      requestToExternal: (request) => {
        if (request === '@wordpress/editor') {
          return ['wp', 'editor'];
        }
        // Return undefined to use default behavior for other modules
        return undefined;
      },
    }),
  ],
};

But that assumes you’re using webpack, not vite. Not sure how to fix this in my case, or why it’s even mapping it wrong in the first place.

Trying to reproduce this based on the information you provided and I can’t.

  1. Added import {PluginDocumentSettingPanel} from '@wordpress/editor'; to the top of a block
  2. Ran the build
  3. No console warnings in dev tools

@eavonius I’ve repeatedly asked you to post your code when creating topics. Please don’t continue to create support requests if you cannot provide steps for us to reproduce your problem.

Please re-read the sticky post on here with our guidelines.

Huh? We use the defaultRequestToExternal and defaultRequestToHandle functions from the @wordpress/dependency-extraction-webpack-plugin in our Vite plugin. Those functions don’t make any assumptions about what build tool is being used.

Sorry that I’ve not posted my code how you expected it. I’d like to figure out how I can do this better here.

I was considering posts here more like “hey I’m seeing an issue here, anyone else seeing this?” before elaborating in more detail. A way to start a conversation basically. I could have overlooked the intent somewhere in the guidelines. If I did, sorry about that.

I think a disconnect for me, is that I didn’t realize posts on this discourse are considered support requests! Now that you’ve said that, I can see why the way I start conversations in posts would be frustrating. I thought it was more a general place to ask questions that you guys sometimes stopped in to read.

I can create a repo with a blank sage theme that just reproduces the problem and point people to that from now on if that would be best?

As an aside, if I just wanted to discuss something with the community that may or may not be an issue - without immediately bothering the primary contributors to consider it urgent, is there a better way to do that? I’m on the discord server too.

I’m not understanding what your expected use of these forums are.

You’re hoping that by posting one line of code and some notices, without showing the full picture, that someone could guess what’s going on? Why would you do that? Why wouldn’t you provide the actual steps required to reproduce your problem?

I’ve linked you the guidelines several times. Have you read them?

https://discourse.roots.io/t/how-to-best-ask-questions-on-this-forum/24582

It doesn’t need to be a repo. It needs to just be a minimum reproducible example, as mentioned in the guidelines.

Like what?

Thanks, yes I have read the guidelines before. I just read them again just to be sure.

Maybe the problem is “minimal code example to reproduce” is subject to interpretation. In looking at the other posts here they all have varying levels of detail.

I think what I’m taking away from all of this is I should just take the extra time to use a repo to share issues.

It seems like the problems I’m having are usually configuration or my specific environment, which aren’t easy for anyone to reproduce without the full picture. It’s probably unrealistic to post that much code on here.

There shouldn’t be this much discussion required to get the minimal reproduction for what you were trying to get help for on this specific topic.

Sharing a repo for an entire theme would not be a minimal reproduction unless you’re only pushing the minimal code required to reproduce the issue…

I’m not going to reply further to this topic, or list it again, unless you provide a minimal reproduction.

Being able to troubleshoot, debug, and provide a minimal reproduction of your issue is necessary to get support. We’re not here to have a constant back-and-forth because you won’t spend more effort up front.

If you are unable to do this, then I have questions about whether or not you should be using the tools in the Roots ecosystem.

Thanks ben, makes sense.

After isolating the code in a blank sage theme, I determined the warnings were actually coming from the Yoast SEO plugin.

Sorry for wasting your time, and thanks for your patience.

1 Like