AssemblyScript/assemblyscript

"A 'declare' modifier cannot be used in an already ambient context" after upgrading to version 0.27.35

haykam821 opened this issue · 3 comments

Bug description

When upgrading to version 0.27.35, I am getting a new error in my builds:

> tsc

../../node_modules/assemblyscript/std/assembly/index.d.ts:2698:3 - error TS1038: A 'declare' modifier cannot be used in an already ambient context.

2698   declare function always<T>(value: T): T;
       ~~~~~~~


Found 1 error in ../../node_modules/assemblyscript/std/assembly/index.d.ts:2698

The changelog for the release does not indicate any particular change that would cause this breakage. The corresponding lines of code appear to be:

export namespace inline {
// @ts-ignore: decorator
@unsafe @builtin
export declare function always<T>(expr: T): T;
}

Steps to reproduce

The particular package that fails to build uses the following TypeScript configuration with tsc:

{
	"compilerOptions": {
		"outDir": "./dist",
		"rootDir": "./src"
	},
	"extends": "assemblyscript/std/assembly.json",
	"include": [
		"./src"
	]
}

AssemblyScript version

v0.27.35

Well, the changelog for 0.27.35 does indeed reference #2895 which is where the new function that came from.

I see you're using tsc not asc, so I presume your code using AssemblyScript's portability features. @CountBleck - perhaps this is a portability issue?

I suppose that's what I get for writing that part on my phone, without IntelliSense...
In any case, the next release (around 12 AM UTC) should fix this.

Thank you! Version 0.27.36 resolved the build issue on my end.

Regarding the tsc mention, right now I have a setup like so:

flowchart TD
    A[Backend app] --> B[Common TypeScript library]
    C[Common AssemblyScript library for managing WASM memory] --> B
    D[AssemblyScript module] --> C
    E[Another AssemblyScript module] --> C
Loading

I'm using tsc to compile the common library while using AssemblyScript's types, then compiling the library into each module. From what I understand, I don't need portability in this case. The editor integration features seem to work a little oddly, but I'm assuming that's from my project structure as opposed to a difference with AssemblyScript, and the issues aren't major enough to be worth debugging anyways.