I'm taking my first steps in Gutenberg block development and I'm already stuck. My block JS script makes use of a couple lodash functions (filter and pick). I'm registering my block using the following function:

function register_block() {
        plugins_url( 'block.build.js', __FILE__ ),
        array( 'wp-blocks', 'wp-components', 'wp-element', 'wp-utils', 'lodash' )

    register_block_type( 'my/block', array(
        'editor_script' => 'block-script',
    ) );

As you can see I'm adding the lodash lib as a dependency, and checking the page source code it's effectively loaded before my plugin's script. However, I'm getting a ReferenceError: pick is not defined console error.

This is the line that calls the pick function:

onSelectImages( images ) {
    this.props.setAttributes( {
        images: images.map( ( image ) => pick( image, [ 'alt', 'caption', 'id', 'url' ] ) ),
    } );

I don't know what I'm doing wrong. Any ideas?

Thanks in advance

  • Related core ticket #43733 for replacing underscore with lodash.
    – birgire
    Apr 25, 2018 at 18:16
  • Are you just calling pick as is? Can you edit your question with the line of code in question?
    – Tom J Nowell
    Apr 25, 2018 at 18:52

2 Answers 2


In the block script I had to replace:

import pick from 'lodash/pick';


const { pick } = lodash;

And now it seems to work for me.

  • 3
    Just as a note for future visitors, the first code block above is for bundler/compilers like webpack/parcel. That will include the pick functionality as part of your bundle. The second code block is runtime code making the pick functionality available from the global lodash library. Of course, the global lodash object must be available at the time the line runs.
    – JakeParis
    Nov 30, 2018 at 15:06

The problem is that lodash isn't a script dependency, it's an NPM dependency:

array( 'wp-blocks', 'wp-components', 'wp-element', 'wp-utils', 'lodash' )

You can't enqueue it this way and expect your application to build. Lodash may be available in WP Admin, but webpack runs in a local Node CLI context, and it doesn't know what lodash is. So instead you need to use npm to acquire the library and include it in your final JS build via babel/webpack/etc. This way webpack/babel know about lodash and can do their job correctly.

  • But Gutenberg itself adds it that way: github.com/WordPress/gutenberg/blob/master/lib/…
    – leemon
    Apr 25, 2018 at 18:39
  • This is incorrect. Since the block editor requires lodash to be an available script, it is available to other scripts via wp_enqueue_script. Of course, you can require the file via npm and include it in your bundle, but that's unnecessarily increasing your bundle size.
    – JakeParis
    Nov 30, 2018 at 15:03
  • @JakeParis on the page lodash is available yes, but that's not the problem the OP is asking about, webpack/babel aren't running in WP Admin, they're running in a Node context, they don't know lodash is available on the webpage when they're building the bundle, or how to deal with it
    – Tom J Nowell
    Dec 1, 2018 at 3:12
  • That makes sense, thanks for clarifing your answer. There are 2 possible solutions to the OP, and yours is the one, and switching out the import statement for the destructuring of lodash is the other. The problem with this solution it's a waste to include lodash in the bundle just to make the build tool know what is meant by pick, as long as it's known that lodash will be available in the global context.
    – JakeParis
    Dec 3, 2018 at 14:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.