fix: corrects resolve for win32 paths #436
Conversation
| done(); | ||
| }); | ||
| }); | ||
| it("should resolve namespaced module names", done => { | ||
| pnpApi.mocks.set("@user/pkg", path.resolve(fixture, "pkg")); | ||
| resolver.resolve({}, __dirname, "@user/pkg", {}, (err, result) => { | ||
| pnpApi.mocks.set(`@user${posixSep}pkg`, path.resolve(fixture, "pkg")); |
There was a problem hiding this comment.
thoughts: i'm not sure about using posixSep in this place, because it should use osBasedPathSeparator (obps) based on reasoning from /test/util/path-separator description of this variables, but this test is mocking pnpapi and resolving it also in this file, so that's the place where I want to think about one more time. Probably, will try to take a look on pnpapi
| absoluteOsBasedPath, | ||
| absoluteOsBasedResolvedPath, | ||
| posixSep: posixPathSeparator, | ||
| obps: osBasedPathSeparator, |
There was a problem hiding this comment.
thoughts: I wanted to use fullname, but this entity being used too often in tests, so I decided to make name shorter
| @@ -0,0 +1,108 @@ | |||
| /* | |||
| MIT License http://www.opensource.org/licenses/mit-license.php | |||
There was a problem hiding this comment.
question: not sure, what I should write here? should I add same author (Author Tobias Koppers @sokra) as other files? sorry, not so much contributing... 🙃
There was a problem hiding this comment.
@davakh You can write own name here
| // Functions below sometime handle transferPathToPosix and based on reading of test file you can see, that | ||
| // sometimes absolute paths started with obps (osBasedPathSeparator) and not absoluteOsBasedPath. That's because we use path.join too much in this test, | ||
| // and it works tricky on platforms: | ||
| // > path.posix.join('/abc/ab', '/abc/de') -> '/abc/ab/abc/de' (correct path after all, ) |
There was a problem hiding this comment.
nitpick: I'll fix it with following changes after review
| @@ -199,7 +202,7 @@ function createOptions(options) { | |||
| } | |||
| } | |||
|
|
|||
| return { | |||
| return normalizeOptionsForWindows({ | |||
There was a problem hiding this comment.
I am afraid it will be slow on big builds...
There was a problem hiding this comment.
Okay, I'll take a look how it integrates with other libraries, maybe I'll find better place to normalize it. Don't really sure how often resolver factory can be called.
| @@ -189,6 +189,8 @@ function getField(content, field) { | |||
| */ | |||
| function cdUp(directory) { | |||
| if (directory === "/") return null; | |||
| if (directory.match(/^[a-zA-Z]:$/)) return null; | |||
There was a problem hiding this comment.
Why we need it? We have unix path internally...
There was a problem hiding this comment.
Because it can be win32 path still. Of course, it has posix char separator, but absolute path can be resolved as X:/something/ for example and for this case - to prevent this function to go up
| @@ -77,10 +79,18 @@ module.exports = class PnpPlugin { | |||
| return; | |||
| } | |||
|
|
|||
| if (typeof resolution === "string") { | |||
| resolution = transformPathToPosix(resolution); | |||
There was a problem hiding this comment.
external path that can be received from pnpapi -> we transform it to path with posix separators in case we get path with win32 separator from pnpapi
| @@ -9,7 +9,6 @@ | |||
| /** @typedef {import("./Resolver").ResolveStepHook} ResolveStepHook */ | |||
|
|
|||
| const slashCode = "/".charCodeAt(0); | |||
| const backslashCode = "\\".charCodeAt(0); | |||
There was a problem hiding this comment.
We can keep it like this, but I thought about removing it because internally we should handle only posix separator char
| @@ -11,7 +11,7 @@ | |||
| */ | |||
| module.exports = function getPaths(path) { | |||
| if (path === "/") return { paths: ["/"], segments: [""] }; | |||
| const parts = path.split(/(.*?[\\/]+)/); | |||
| const parts = path.split(/(.*?[/]+)/); | |||
There was a problem hiding this comment.
Same idea as this: #436 (comment)
That's what I did, that's how it works right now in this PR: we convert the external paths, we can get it in So, actually, we convert win32 path to posix path only in case of UPDATE: Okay, I think that I got where the misunderstanding comes from: I'm thinking more about using win32 paths still but with posix path separator - because node.js supports this. So for me, it means we work with relative type of path (win32/posix) based on OS, but we have posix separator in win32 paths instead of win32 separator and it's still win32 type path. |
fixes #401
accidentaly closed previous PR: #402