Add tests for asconfig and windows

[willemneal]

This tests checks if an entry file from another project imports from a relative path it is found on windows.

• I've read the contributing guidelines

[willemneal]

@dcodeIO As I had suspected the issue is here:

> @ test D:\a\assemblyscript\assemblyscript\tests\asconfig\entry-points\node-resolution
> node ../../index.js

[2 parse error(s)]
ERROR TS6054: File 'globalTwo.ts' not found.

 import "./globalTwo";
        ~~~~~~~~~~~~~
 in ..\assembly\globals.ts(2,8)

[dcodeIO]

Hmm, that's a strange error, especially because Windows doesn't really care about capitalization in file names. Would rather expect *nix to fail if it was that.

[willemneal]

@dcodeIO could we make this an issue and just merge the patch for now?

[dcodeIO]

I'd prefer to find out what's actually wrong there.

Tried this locally now, and what I can tell so far is that the problem happens in test:asconfig/entry-points/nested, with

• entry = assembly/globals.ts
• asconfigDir = C:\path\to\assemblyscript\tests\asconfig\entry-points
• baseDir = .

and the output of optionsUtil.resolvePath(entry, asconfigDir) being C:\path\to\assemblyscript\tests\asconfig\entry-points\assembly\globals.ts, ultimately resulting in ERROR TS6054: File 'globalTwo.ts' not found..

Looks like this has something to do with absolute paths coming from the require.resolve branch in resolvePath, but might even be general for all absolute paths.

The corresponding counterpart on Linux is

• entry = assembly/globals.ts
• asconfigDir = ..
• baseDir = .

with output ../assembly/globals.ts, indicating that something works differently there.

[dcodeIO]

Diving a little deeper into it, the problem appears to be the call to readFile in getAsconfig reading a different file on Windows than on Linux, even though file=asconfig.json and baseDir=. are the same. On Windows, it loads entry-points/node-resolution/asconfig.json, while on Linux it loads entry-points/nested/asconfig.json. In particular, it appears that both commands are operating on a different process.cwd(), indicated by the directory used to look up asconfig.json.

[willemneal]

How could process.cwd() be different?

[dcodeIO]

That's the question. On Windows, it is C:\path\to\assemblyscript\tests\asconfig\entry-points while on Linux it is /path/to/assemblyscript/tests/asconfig/entry-points/nested when executing test:nested. Might have something to do with a difference on propagating cwd in npm scripts, but just guessing.

[dcodeIO]

False alarm, I was executing a different test.

[dcodeIO]

I see the problem now. At

assemblyscript/cli/asc.js

Line 661 in 348c42b

assemblyscript.parse(program, sourceText, sourcePath, true);

sourcePath is ..\assembly\globals.ts on Windows, but internal

assemblyscript/src/util/path.ts

Line 20 in 348c42b

export function normalizePath(path: string): string {

where the path ultimately ends at is supposed to be dealing with Unix-like paths, in turn normalizing differently. Adding a path = path.replaceAll("\\", "/"); to normalizePath fixes the problem.

[willemneal]

Great! Can you push those changes to this branch? You should have the permissions since it's a PR to this repo?

[dcodeIO]

Yes, can push it here. Still looking for the best place to fix it at.

[dcodeIO]

Thanks! :)

[github-actions]

🎉 This PR is included in version 0.14.7 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀