Fixes ScriptPath for script paths with query strings #28
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi there, thank you for publishing such a great project! I've just been getting a demo up and running using Visual Studio 2017 (using standard VS templates). By default, the VS/webpack toolchain will append a version hash query string to its script bundle references. e.g:
http://localhost:59090/dist/main.js?v=hyw4nPT-JXNYaAsGUUqAfkThIaWT7qch0FVyfgwK9zg
The ScriptPath object purposefully throws an exception in order to extract the script path from the stack trace. A regular expression is used to extract the path components. The expression does not expect a query string in the script path.
In my particular case, the stack trace string with the query string on the script path looks like this:
This fails with error:
If we purposefully omit the query string like so:
at Object.module.exports (http://localhost:59090/dist/main.js:2884:211)
It works.
As a fix we can update the regular expression to lazily match any character 0 or more times between the file extension (js|html) and the first instance of the colon character (which in this context, indicates the end of the path).
I applied this fix in my local development environment and had no further issues and also confirmed with a web-based visual regular expression debugger that both forms are correctly parsed.
Thanks!