Debug plugins

  • Develop and test unreleased Blockly changes in conjunction with blockly-samples plugins using npm link to create a symbolic link.

  • This method facilitates debugging by allowing access to sourcemaps and enabling the use of local, unpushed Blockly changes.

  • After building and packaging Blockly, use npm link in its dist directory, and then link it within your blockly-samples project.

  • Remember to rebuild and repackage Blockly after each core change, and restore blockly-samples using npm ci when testing is complete.

Sometimes when developing a plugin in blockly-samples, you'll need to make corresponding changes in Blockly itself. Most plugins are set up to fetch Blockly from the npm registry, so you'd only be able to use code that has already been released on npm. This would make debugging your Blockly changes difficult. When you want to make and test changes in both blockly and blockly- samples, you can use npm link to test your unreleased changes together.

You can tell npm to use a package from your machine instead of fetching the package from the npm registry. Using this method, you should have access to sourcemaps that make debugging blockly easier. You can use this method with changes in core that haven't yet been pushed to GitHub.

  1. In your fork of blockly:

    $ npm run package
$ cd dist
$ npm link

    These steps build core Blockly, package it, then create a symlink to the packaged files.

  2. In your fork of blockly-samples, at root:

    $ npm link blockly

    This step tells npm to look for the symlink you created earlier instead of fetching the package from npm.

  3. npm run start from the plugin's directory to test your plugin.

When you make changes in core, you'll have to rebuild and repackage it.

When you're finished testing, run npm ci at the root level of blockly-samples to reset the state of your repository.