Importing a class stops its functions from being in wasm output

[kungfooman]

For some reason when I do import {ClassB} from "./B"; in assembly/A.ts then the stuff out of assembly/B.ts isn't in build/untouched.wasm anymore.

This is a minimal repro:

assembly/A.ts

//import {ClassB} from "./B";
export class ClassA {
	doA():f32 {
		return 123.0;
	}
}

assembly/B.ts

export class ClassB {
	doB():f32 {
		return 123456.0;
	}
}

doit.sh

# print the commands via -x/+y
set -x

time npx asc \
assembly/A.ts \
assembly/B.ts \
-b build/untouched.wasm -t build/untouched.wat --sourceMap --validate --debug

set +x

Then everything is exported:

as@euve254883:~/public_html/MathAS$ ./doit.sh
as@euve254883:~/public_html/MathAS$ strings build/untouched.wasm | grep Class
ClassA#doA
ClassB#doB
assembly/A/ClassA#doA
assembly/B/ClassB#doB

However, if you now uncomment the first line in assembly/A.ts:

import {ClassB} from "./B";
export class ClassA {
	doA():f32 {
		return 123.0;
	}
}

Then the stuff from ClassB isn't in the build/untouched.wasm anymore:

as@euve254883:~/public_html/MathAS$ ./doit.sh
as@euve254883:~/public_html/MathAS$ strings build/untouched.wasm | grep Class
ClassA#doA
assembly/A/ClassA#doA

[dcodeIO]

Appears to be an edge case when using multiple entry files. I think what happens here is that module export status becomes overridden when elements are linked in between entry files. Just came accross that in the resolver rework as well and are looking for a better implementation now.

[MaxGraey]

@dcodeIO Is it still issue after reworked resolver? WDYT?

[dcodeIO]

Closing this issue as part of 2020 vacuum because it appears to have been fixed meanwhile. Please reopen if it isn't.