Conversation
… new lib functions
|
I think we should probably disable translation tests in this branch until we are ready to finish this branch. There are a couple clean-up and refactorings I can see would be nice here, but let's also do that once we actually settle on a nice solution. |
|
Personally I don't mind having them on because it gives me something to look and and ensure the output is what I expect to see in a lot of situations, but I won't worry about updating them until it's done. For JSONStringify, how would you feel about "injecting" the declaration in tranpsileString, in util.ts? It could either be baked into the current version, or with a custom alternate version: export function transpileStringWithJSONUtil(str: string, options?: CompilerOptions): string {
return transpileString("/** !NoContext */ declare function JSONStringify(t: any): string;\n" + str, options);
} |
|
I think injecting it inside transpileString is a fine solution, that function is only for testing anyway. |
|
Dont do it in transpileString, that function is used in the online compiler and is part of the public API. |
|
Oh it was moved. Should be no big deal to wrap the compiler function in |
|
Yes, I saw that - currently I've overridden the one exposed via util so it only affects tests: //util.ts
import { transpileString as _transpileString } from "../../src/Compiler";
export function transpileString(str: string, options?: CompilerOptions): string {
return _transpileString("/** !NoContext */ declare function JSONStringify(t: any): string;\n" + str, options);
} |
3 participants
This PR gets the new system working. All functions have an initial context parameter and are called with either a colon or '_G' as the first parameter. Lib functions for bind(), apply() and call() have been added. All tests are updated so they pass.
Notes:
Issues:
I had to disable a tslint rule in the new lib functions because I needed to declare the passed-in function with the new decorator so 'this' can be swapped. But decorators only work on function decls that are interfaces, not type aliases. Allowing decorators on aliases should be investigated.<-Turned out to be an easy fix.