Potential false positive path traversal with REST on some hosting providers

[aaronware]

What is the issue?

For hosting providers that have proactive WAF rules (In this case Pressable), there may be potential issues with relative paths within code examples that are being documented. When transmitted via the pages API code examples with relative ../ are being treated as path traversal exploits in code blocks/examples.

How to reproduce

Have a plugin that has relative paths within javascript that will be output such as...

import { MantlePanels } from '../../slots';

How can you fix / workaround

Wondering if the action that is doing the transmission could log a more robust response when receiving a 406 error and/or potentially provide examples for using @ style aliases within webpack configs

It's a better cleaner practice and may give guidance when onboard if documenting a react heavy project with relative path imports as part of webpack

Your webpack.config.js already has a resolve.alias block — currently only pinning date-fns. Adding one for the shared internals:

alias: {
  ...defaultConfig.resolve?.alias,
  'date-fns': path.resolve( __dirname, 'node_modules/date-fns' ),
  '@slots':   path.resolve( __dirname, './src/slots' ),
},

Other Notes

I am not sure if there is some specific escaping that could be done to help other devs, there is technically a "better way" with aliases. My first test was on an older codebase. This came up in our initial testing of a react UI in the admin and 12 of 25 pages for a plugin did not make it to to docs due to a 406 response from the hosting provider.

I did not confirm if this happens with other coding languages but was able to confirm it with the hosting provider we are using for this test implementation and react.