asconfig: entries cannot include * and ** wildcards

[jerrygreen]

I have further asconfig.json:

{
  "entries": ["./src/asm/**/*.as.ts"]
}

Which is similar to running:

asc ./src/asm/**/*.as.ts

And the above CLI command works... But if I run this config instead, I get this error:

asc --config asconfig.json
ERROR TS6054: File 'src/asm/**/*.as.ts' not found.

FAILURE 1 parse error(s)

It's clear bash translates those * and ** into actual file hierarchy list, while compiler can't understand those globs and rely too much on bash. This way I can't make some scripting work.

I'd recommend to use something like globby when parsing asconfig.json, to make it a bit more independent from bash, and a little more similar to how tsc work (I see there's a lot of inspiration from it 😜)

[dcodeIO]

May I ask what your use case for so many entries is?

[jerrygreen]

@dcodeIO well, currently I only have just 2, but I just started a project, and expect to add more files, and wouldn't like to manually list them in some config each damn time, - this disturbs the flow. So this feature would be handy

[dcodeIO]

It's just that I typically don't see more than one, or maybe two, entry files, since these are somewhat independent programs resulting in Wasm module exports, so I am curious what you are planning to do with a bunch of them. Even the compiler for example has just two entry files (index + glue).

[jerrygreen]

@dcodeIO I'm making some kind of a game, like indie project. Currently it's barely a game: I have just game loop written in TypeScript, and a dozen flying circles and rectangles:

I expect some parts of it to be made in AssemblyScript, like for example procedural map generation, maybe something else, maybe even game logic. All that is kinda experimental, and I don't know how much I'll benefit from using AssemblyScript, but I think it might be helpful, so...

[dcodeIO]

Thanks. How would it benefit from more than one entry file though, that is exporting all things the program needs? Other than that, I am not opposed to add glob-matching, but we'd need a plan to port say glob to AS eventually, on top of WASI APIs or so.

[jerrygreen]

@dcodeIO how it would benefit from more than one file entry? Logic separated into different files, basically.

Honestly I don’t yet know how much code I’d like to place into AssemblyScript yet. Part of the reason is that WASM can’t have direct access to canvas or ctx (canvas context). I don’t have any performance metrics but I imagine if I’d want to make some rendering calculated in AssemblyScript, I’ll still need to render all it with TypeScript, so it might be even worse than doing all that in just TypeScript, because instead of one big loop I’ll have two big loops, and any benefit might turn into nothing. In web applications a couple extra loops is often “meh, whatever”, but in games you have like 16 milliseconds to render the whole scene, to maintain 60 frames per second, so every extra millisecond counts.

Anyway in general I might want some environment map generation logic stored in one AssemblyScript file, some function related to physics, - in another, Navigation Mesh in third, etc.

glob on top of WASI API? You’d know better, though I think it should be treated separately, and parsing asconfig.json has nothing to do with WASI API.

[dcodeIO]

Mentioning WASI because the plan is to move all of asc to WASM eventually. Its dependencies are relatively simple currently, but glob seems as it could be a little more than that, so mentioning since having that in mind already may help in case someone would like to experiment with an implementation.

Regarding accessing canvas etc., my intuition is that as long as a use case can utilize linear memory, by for example copying data directly to the GPU with WebGL, there should be benefits, but interaction with pure Web APIs may indeed bottleneck at other places in the current state of Wasm.

[jerrygreen]

@dcodeIO may I ask you how it turned out you have ./cli/asc.js and ./cli/asc.d.ts and not just ./cli.ts, where asc.js and asc.d.ts generated automatically based on that? Do you write .d.ts manually? Like poor man's DefinitelyTyped?? (except DefinitelyTyped don't have access to change sources, so it's understandable why they write it manually)

You said you're "not opposed to add glob-matching", so I though I might have a look and probably add it, but I'm a little confused with what I see in sources

[dcodeIO]

To me, using TypeScript is an unnecessary burden for simple stuff like that. Another build step, multiple files that can be mistaken for the actual sources, being limited by the TS compiler when it comes to new or uncommon JS features. Mostly my preference, and it's perfectly fine to disagree with it.

[MaxGraey]

AssemblyScript tries to keep the number of dependencies to a minimum, and those that are available are mostly polyfills for JS. This is due to the fact that the compiler itself already self-compiled and I hope it will be able fully launched on standalone wasm runtimes like wasmtime. With js-only dependencies like glob / globbly / fast-glob this won't be possible. Thus, we are forced to either exclude this possibility or completely port "globby" to AssemblyScript with WASI support