| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
I do not think we should start including explicit special cases in node core for third party libraries like this. We should be solving this in a more generic way if there is not already some generic API/interface that suffices for webpack.
Sorry, something went wrong.
|
@mscdex take another look, I abstracted the logic so that it should apply to any paths with a scheme; I think the resolve logic would have potentially been broken for file:// paths prior to this. |
Sorry, something went wrong.
Based on advice from webpack project, this PR stops trying to resolve sources with a webpack:// scheme (or other schemes, as they represent absolute URLs). Source content is now loaded from the sourcesContent lookup, if it is populated (allowing for non file:// schemes). Refs: nodejs#35325
Sorry, something went wrong.
Co-authored-by: devsnek <me@gus.host>
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
Sorry, something went wrong.
|
👋 if no one objects, I'd like to land this towards the end of the day, since there are a few additional fixes I'd like to make to source-map handling which build on this. |
Sorry, something went wrong.
There was a problem hiding this comment.
lgtm
Sorry, something went wrong.
We were incorrectly trying to run path.resolve on absolute sources URLs. This was breaking webpack:// URLs in stack trace output. Refs: #35325 PR-URL: #35903 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
We were incorrectly trying to run path.resolve on absolute sources URLs. This was breaking webpack:// URLs in stack trace output. Refs: #35325 PR-URL: #35903 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
We were incorrectly trying to run path.resolve on absolute sources URLs. This was breaking webpack:// URLs in stack trace output. Refs: nodejs#35325 PR-URL: nodejs#35903 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
We were incorrectly trying to run path.resolve on absolute sources URLs. This was breaking webpack:// URLs in stack trace output. Refs: #35325 PR-URL: #35903 Backport-PR-URL: #37717 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
| Back | FazBrowse Home | New Git URL |
Based on advice from webpack project, this PR stops trying to resolve
sources with a webpack:// scheme (or other schemes, as they represent
absolute URLs). Source content is now loaded from the sourcesContent
lookup, if it is populated (allowing for non file:// schemes).
stack-trace:
webpack:///./webpack.js:14 throw new Error('oh no!') ^ Error: oh no! at o (/Users/bencoe/oss/node-1/test/fixtures/source-map/webpack.js:1:970) -> webpack:///./webpack.js:14:9 at n (/Users/bencoe/oss/node-1/test/fixtures/source-map/webpack.js:1:952) -> webpack:///./webpack.js:10:3This work is in pursuit of #35325
Refs webpack/webpack#9601
Checklist
CC: @sokra, @nodejs/tooling