Interface imports in output files

[KoltesDigital]

I'm submitting a bug report

• Library Version:
  aurelia-binding: 2.3.0
  aurelia-templating: 1.10.2

• Language:
  all

Current behavior:
aurelia-templating's output files (in dist/es2015, dist/native-modules, and dist/system but the latter does not lead to an error) import interfaces from aurelia-binding. Since they do not exist in aurelia-binding's output files, they can't be imported at runtime.

SyntaxError: The requested module '...' does not provide an export named 'Scope'

Expected/desired behavior:
Interfaces should not be imported in the output files.

[bigopon]

@KoltesDigital May i know your app setup?

[KoltesDigital]

@bigopon I'm trying to make an Aurelia project (almost empty in itself) work with JSPM 2. You can read jspm/jspm-cli#2454 while I commit the project state.

[KoltesDigital]

Available on https://github.com/KoltesDigital/example-ts-jspm-aurelia/tree/531bdefb847001ce98679b0a8e15de47d3f87152

[bigopon]

@KoltesDigital thanks. I'll have a look at the build

[bigopon]

@EisenbergEffect Scope is used in only 1 place here

templating/src/binding-language.js

Line 23 in ea994d1

bind(source: Scope): void;

We can degrade the interface to any and remove the Scope import to avoid the issue, or i can convert this module in TS as well, which one would be better?

[KoltesDigital]

My two cents, you shouldn't degrade the code, i.e. lose guarantees that the code is correct. Scope is not the only problematic interface, I saw at least two other ones. I believe it would be better to configure the transpiler to not output interfaces, which ts does... But I don't know at all your release process.

[bigopon]

@KoltesDigital I've checked the build, it's an old process so we probably don't want to touch that part. Beside that, let binding is not what you would use directly, so its interface, even when degraded to any, will still be ok.

[KoltesDigital]

Agreed. What about Binding (interface) and Expression (class!)?

[EisenbergEffect]

@bigopon I'd do the minimum we can to resolve @KoltesDigital 's issue. I'm wary of a big conversion or removing anything that was previously published in the dts. If widening a type can address the issue, I think that's ok for now. As you know, these issues are solved automatically for vNext by virtue of it all being TS and the new build processes there.

[KoltesDigital]

Good news for vNext, I haven't followed up. Well this issue appeared because I tested JSPM 2 which is still in progress too... I better stay on JSPM 0.17 for now, and hopefully both libraries will be ready soon.