Customize / make more readable output of promise new promise (promise based dynamic remotes)
See original GitHub issueFeature request
What is the expected behavior? Promise new promise syntax (promised based dynamic remotes) gives excellent flexibility in defining remotes. However, the build output of this is too verbose, showing the entire body of the function in the build output.
What is motivation or use case for adding/changing the behavior? Promise based dynamic remotes give great flexibility. But, the build output is hard to read, particularly when more than 1 promised based dynamic remote is specified. Other details of the build output can be obscured by the volume of the promised based dynamic remote output.
How should this be implemented in your opinion? It looks like this output comes from the readableIdentifier function in ExternalModule.js. readableIdentifier appears to be part of the Module class, and is implemented differently for different module types. For external modules, it looks like this:
/**
* @param {RequestShortener} requestShortener the request shortener
* @returns {string} a user readable identifier of the module
*/
readableIdentifier(requestShortener) {
return "external " + JSON.stringify(this.request);
}
One possibly naive revision would be to truncate the stringified output to some maximum length. For example, change ExternalModule.js’ method to look like this:
/**
* @param {RequestShortener} requestShortener the request shortener
* @returns {string} a user readable identifier of the module
*/
readableIdentifier(requestShortener) {
const maxLength = 80;
const stringifiedRequest = JSON.stringify(this.request);
return "external " + (stringifiedRequest.length > maxLength ? stringifiedRequest.substring(0, maxLength) + '...': stringifiedRequest)
}
Are you willing to work on this yourself? yes, although someone else likely has a better understanding. I’d be happy to test and otherwise assist
Issue Analytics
- State:
- Created 10 months ago
- Comments:17 (8 by maintainers)

Top Related StackOverflow Question
@alexander-akait , the update snapshots helped with some of the unit test problems. But I’ve also changed the behaviour, limiting the scope of where the readable identifier is potentially truncated. I only care about the external modules, and some of the tests were having problems with the broader shortening behaviour. So, I changed the wrapper function to take the module, and only perform the shortening if it’s an external module type, and the readable identifier is “too long”. Here’s what the new function looks like:
and here’s an example usage:
Hi Zack,
Thanks for your reply. I have no idea what it means though. Can you please elaborate?