Absolute import path slashes normalized#390
Conversation
|
Could you add a couple tests for this? You can probably do something like: util.transpileString(`import * from "somePath";`, { rootPath: "Test/Root/Path" }) |
|
Added some require tests. It got a bit odd trying to figure out how to use In The behavior of From what I understand...
Hope this is ok, just trying to keep the behavior of the options the same. |
|
Thanks for adding the tests. I'm happy with the PR, the only unknown for me now is the behavior of those config options. To clarify: We aim to have these options work the same in |
src/LuaTransformer.ts
Outdated
| .replace(".\\", "") | ||
| .replace("./", "") | ||
| .replace("/", ".") | ||
| .replace("\\", "."); |
There was a problem hiding this comment.
Backslashes can be used in filenames in some POSIX environments and should not be replaced on POSIX.
Ideally filePath should be converted using nodes path lib, maybe just using path.sep (https://nodejs.org/api/path.html#path_path_sep) is enough.
There was a problem hiding this comment.
Can TypeScript and Lua reference a module on a POSIX system with a backslash in its name?
There was a problem hiding this comment.
Not sure, never tried it. Nevertheless it would be nicer to use a platform independent solution here.
There was a problem hiding this comment.
I didn't use path.sep because Windows paths can have either one of the slashes. But I have made it so non-win32 systems do not have their backslashes removed.
| private getImportPath(relativePath: string): string { | ||
| // Calculate absolute path to import | ||
| const absolutePathToImport = this.getAbsoluteImportPath(relativePath); | ||
| if (this.options.rootDir) { |
There was a problem hiding this comment.
While I agree that the rootDir Implementation is a bit weird and needs a rework, along side with baseUrl(s) you should not just remove it.
This will break paths that include files from a parent directory.
For example 2 files src/lib.ts and src/subdir/subdir2/nested.ts
nested.ts:
import * as lib from "../../lib.ts
The above should get converted to require("lib"). Which I think is what the current implementation does via path.resolve and replace.
Probably one of the oldest pieces of code in this project, which could explain why there are no tests for it.
So please also add tests for paths with ...
EDIT:
FYI rootDir is always set: If not specified via CLI or config rootDir is set to the project or working directory.
There was a problem hiding this comment.
Thanks for the info, I'll keep this use case working by adding the code back.
My current tests are just matching the literal string in the require path to what you'd expect in a Lua program.
I don't think I can add add tests for .. since to test the workaround functionally there may need to be a testing tool to execute a Lua project involving multiple files at different locations.
I'll add the code back but I can't figure out how to build some test cases for it.
There was a problem hiding this comment.
Figured out a way to test .. paths, modified Compiler.ts to do it.
| private pathToLuaRequirePath(filePath: string): string { | ||
| return filePath.replace(/\.json$/, '').replace(new RegExp("\\\\|\/", "g"), "."); | ||
| private formatPathToLuaPath(filePath: string): string { | ||
| if (process.platform === "win32") { |
There was a problem hiding this comment.
Lost during merge:
| if (process.platform === "win32") { | |
| filePath = filePath.replace(/\.json$/, ''); | |
| if (process.platform === "win32") { |
There was a problem hiding this comment.
Good find, adding that back
src/LuaTransformer.ts
Outdated
| .replace(/\.\//g, "") | ||
| .replace(/\//g, "."); | ||
| .replace(/\//g, ".") | ||
| .replace(/\.json$/, ""); |
There was a problem hiding this comment.
Could you do the json replacement fist? Otherwise it would break modules named json, see #418.
src/LuaTransformer.ts
Outdated
| .replace(/\\/g, "."); | ||
| } | ||
| return filePath | ||
| .replace(/\.json$/, "") |
There was a problem hiding this comment.
It should be before windows part as well. Or, maybe, just make windows part replace backslashes with slashes to make it cleaner?
I've noticed
getImportPathwill createabsolutePathToImportwhich contains backslashes on Windows.rootDirseems to always use forward slashes.So when this happens:
rootDirmay not be subtracted fromaboluteImportPathcorrectly.This results in something like:
This PR is just to ensure that
absolutePathToImportcontains forward slashes to correct the require path whenrootDiris used.