-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for --types #960
Conversation
@ry ok, it appears to be finally ready to go, if you are happy with the unit tests (and there is further review by @piscisaureus) cc: @dsherret |
for (const enumName of enumNames) { | ||
const enumDeclaration = sourceFile.getEnumOrThrow(enumName); | ||
enumDeclaration.setHasDeclareKeyword(false); | ||
output += enumDeclaration.getText(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You probably already know this and not sure if it's necessary here, but just take note that .getText()
does not include the js docs. If you want that, there is a .getText(true)
argument that will include the js docs when getting the text (not a fan of obscure boolean parameters, but this patterns off getStart(includeJsDocComments = false)
from the compiler api).
Also note, .getText()
returns the text without leading trivia (comments & whitespace) while .getFullText()
returns the text with leading trivia.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Specifically here the generated declaration file includes a useless generated JSDoc comment so it is intentional, but I should comment that.
// ./node_modules/.bin/ts-node --project tools/ts_library_builder/tsconfig.json tools/ts_library_builder/main_test.ts | ||
|
||
import "./ast_util_test"; | ||
import "./build_library_test"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rename main_test.ts
to test.ts
This isn't hooked into tools/test.py
yet. Add the following to tools/unit_tests.py
, and check that tools/test.py
fails if you change an assert inside one of your tests:
run([
"node",
"./node_modules/.bin/ts-node",
"--project",
"tools/ts_library_builder/tsconfig.json",
"tools/ts_library_builder/test.ts"
])
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI I'd like to land #958 before this, so that we can also get the benefit of output checking.
variableDeclarations[2].getType().getText(), | ||
`typeof import("bazqat").moduleC.qat` | ||
); | ||
assertEqual(variableDeclarations.length, 3); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great. Thanks!
Move these into test.ts
test(function astUtilNormalizeSlashes() { | ||
// TODO build out | ||
assert(!!normalizeSlashes); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need to add all these stubs - it's just more to maintain. Just put all the tests into test.ts
.
@kitsonk Do you have a grip on how hard it would be to use the TypeScript AST for this rather than the simple-ast wrapper? |
tools/ts_library_builder/ast_util.ts
Outdated
}); | ||
} | ||
|
||
/** Add `@source` comment to node. */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does a URL make more sense?
I think we're mostly doing this for our imaginative users who don't have the source code checked out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I was doing it to be able to see where it came from when chasing down issues... I think also in the future, if an interface or API pops into the generated library and we want to not "leak" it and want to mark it with @internal
, being able to determine that in debug mode would make it easier. @url
can make more sense/is a more standard JSDoc pragma.
src/flags.rs
Outdated
@@ -58,7 +59,8 @@ pub fn print_usage() { | |||
-D or --log-debug Log debug output. | |||
-h or --help Print this message. | |||
--v8-options Print V8 command line options. | |||
--deps Print module dependencies." | |||
--deps Print module dependencies. | |||
--types Print global environment types." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe better: print typescript declarations for the deno standard library
.
cc @ry
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Print runtime typescript declarations."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Print the type declarations for the runtime environment.
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Crossed the streams... I will go with what @ry suggested.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest to add find_exts("tools/ts_library_builder", ".js", ".json", ".ts", ".md")
to tools/format.py
so all these files get formatted.
Sorry @piscisaureus I didn't see your feedback before doing my latest push. I agree with all of it and will address it. As far as the native TypeScript AST, I have always found it a bit obtuse. It isn't anything like any of the ES ASTs that I have used before, it is largely based on Roselyn (so C#-esque) which makes sense to Microsoft compiler folks but not to me personally. The |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. This is great!
@ry land when you think it's ready
@kitsonk Still missing integration into tools/unit_tests.py |
@kitsonk rebase to master and apply this patch (but squash it into your commits) From d8c0913984e4b97b133bf85ba5b4e9d3c639249d Mon Sep 17 00:00:00 2001
From: Ryan Dahl <ry@tinyclouds.org>
Date: Thu, 11 Oct 2018 17:47:14 -0400
Subject: [PATCH] Add tools/ts_library_builder/test.ts to unit_tests/py
---
tools/unit_tests.py | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/tools/unit_tests.py b/tools/unit_tests.py
index b9be484..14f1d18 100755
--- a/tools/unit_tests.py
+++ b/tools/unit_tests.py
@@ -4,9 +4,7 @@ import sys
import subprocess
import re
-
-def run_unit_test(deno_exe, permStr, flags=[]):
- cmd = [deno_exe, "--reload", "js/unit_tests.ts", permStr] + flags
+def run_unit_test2(cmd):
process = subprocess.Popen(
cmd,
bufsize=1,
@@ -28,6 +26,10 @@ def run_unit_test(deno_exe, permStr, flags=[]):
if errcode != 0:
sys.exit(errcode)
+def run_unit_test(deno_exe, permStr, flags=[]):
+ cmd = [deno_exe, "--reload", "js/unit_tests.ts", permStr] + flags
+ run_unit_test2(cmd)
+
# We want to test many ops in deno which have different behavior depending on
# the permissions set. These tests can specify which permissions they expect,
@@ -43,6 +45,16 @@ def unit_tests(deno_exe):
# TODO We might accidentally miss some. We should be smarter about which we
# run. Maybe we can use the "filtered out" number to check this.
+ # These are not strictly unit tests for Deno, but for ts_library_builder.
+ # They run under Node, but use the same //js/testing/ library.
+ run_unit_test2([
+ "node",
+ "./node_modules/.bin/ts-node",
+ "--project",
+ "tools/ts_library_builder/tsconfig.json",
+ "tools/ts_library_builder/test.ts"
+ ])
+
if __name__ == '__main__':
if len(sys.argv) < 2:
--
2.15.0
|
Landing with above patch in #967 |
Resolve #632
This is a continuation of previous pull requests (#952 and #729) which addresses additional feedback and includes basic unit tests for the
ts_library_builder
.