Skip to content
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

refactor: TS compiler and module graph #5817

Merged
merged 20 commits into from
May 29, 2020

Conversation

bartlomieju
Copy link
Member

@bartlomieju bartlomieju commented May 24, 2020

This PR addresses many problems with module graph loading
introduced in #5029, as well as many long standing issues.

"ModuleGraphLoader" has been wired to "ModuleLoader" implemented
on "State" - that means that dependency analysis and fetching is done
before spinning up TS compiler worker.

Basic dependency tracking for TS compilation has been implemented.

Errors caused by import statements are now annotated with import
location.

Fixes #1692
Fixes #5080
Fixes #5419
Fixes #5815
Fixes #5900

cli/state.rs Outdated
Comment on lines 364 to 373
let module_specifier = module_specifier.clone();
let state = self.borrow();
let target_lib = state.target_lib.clone();
let maybe_import_map = state.import_map.clone();
let permissions = if state.is_main && !is_dyn_import {
Permissions::allow_all()
} else {
state.permissions.clone()
};
let global_state = state.global_state.clone();
Copy link
Member Author

@bartlomieju bartlomieju May 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation of this method requires to solve issue described in #1692 as well.

Currently TS compiler is spun up during fetch_compiled_module() call - if root module was already compiled and hasn't changed then cached code will be used. If one of root's dependencies has changed then TS compiler will be spun up.

Implementing prepare_load() means that we need to manually handle outdated dependencies - because prepare_load() is the only function that can spin up TS compiler. load() will only access already compiled source code in $DENO_DIR, but it won't be able to spin up TS compiler.

CC @kitsonk @ry

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added basic handling of cache invalidation by saving dependency list in "module graph" meta file.

@ry ry mentioned this pull request May 25, 2020
6 tasks
cli/state.rs Show resolved Hide resolved
cli/global_state.rs Outdated Show resolved Hide resolved
cli/global_state.rs Show resolved Hide resolved
cli/main.rs Outdated Show resolved Hide resolved
cli/module_graph.rs Show resolved Hide resolved
cli/state.rs Show resolved Hide resolved
cli/tsc.rs Show resolved Hide resolved
cli/tsc.rs Show resolved Hide resolved
) -> std::io::Result<()> {
let version_hash =
crate::checksum::gen(vec![version::DENO.as_bytes(), &self.config.hash]);
let mut deps = vec![];
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function should discriminate files that were compiled to JS as well as other auxiliary files (like type definitions)

@bartlomieju bartlomieju added the cli related to cli/ dir label May 26, 2020
Copy link
Contributor

@kitsonk kitsonk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few comments.

cli/main.rs Outdated Show resolved Hide resolved
(the following is a syntax error ^^ ! )
~~~~~~~~~
at [WILDCARD]tests/error_syntax.js:3:6
error: Expected Comma, got Some(Word(following)) at [WILDCARD]tests/error_syntax.js:3:5
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to improve these over time, as got Some(Word(follow)) is pretty inaccessible to developers. Ultimately we want go grab the source line and highlight the span, and put some sort of match in to humanise the errors.

@@ -1,2 +1 @@
error: Uncaught SyntaxError: Unexpected end of input
at [WILDCARD]tests/error_syntax_empty_trailing_line.mjs:[WILDCARD]
error: Unexpected eof at [WILDCARD]tests/error_syntax_empty_trailing_line.mjs:2:21
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the same here... "eof" is sometimes well understood, but "Unexpected end of file" is clearer. No sense in holding up this PR, but maybe we should have a DX issue for error messages for this. Hopefully something the wider community would help out with.

@katywings
Copy link

Secretly hoping that this might solve my issues regarding #5665 😅

@bartlomieju
Copy link
Member Author

Secretly hoping that this might solve my issues regarding #5665 😅

@katywings not really, that's a tangential issue with "deno bundle" which is tracked here #4542

@bartlomieju bartlomieju requested a review from ry May 28, 2020 13:20
cli/module_graph.rs Outdated Show resolved Hide resolved
fn load(
&self,
module_specifier: &ModuleSpecifier,
maybe_referrer: Option<ModuleSpecifier>,
is_dyn_import: bool,
_is_dyn_import: bool,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit confused about this is_dyn_import argument. What was its purpose before? Why is it not needed anymore?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was used for permission checks - it is still used, but in prepare_load() function (for the same purpose).

With this PR calling ModuleLoader.load() results in loading already cached file; all of the permission check, etc. are done during building of module graph

cli/tests/integration_tests.rs Outdated Show resolved Hide resolved
cli/tests/integration_tests.rs Outdated Show resolved Hide resolved
cli/tsc.rs Show resolved Hide resolved
@bartlomieju bartlomieju changed the title [WIP] refactor: TS compiler and module graph refactor: TS compiler and module graph May 29, 2020
Copy link
Member

@ry ry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - I'm very happy you've finally laid #1692 to rest

@bartlomieju
Copy link
Member Author

LGTM - I'm very happy you've finally laid #1692 to rest

This PR introduces first pass of fix for #1692 - it essentially does what #5094 is supposed to do. I'm sure we'll be iterating on this issue further.

@bartlomieju bartlomieju merged commit ad6d2a7 into denoland:master May 29, 2020
@bartlomieju bartlomieju deleted the module_loader_prepare2 branch May 29, 2020 14:32
bartlomieju added a commit to bartlomieju/deno that referenced this pull request Jun 5, 2020
This PR addresses many problems with module graph loading
introduced in denoland#5029, as well as many long standing issues.

"ModuleGraphLoader" has been wired to "ModuleLoader" implemented
on "State" - that means that dependency analysis and fetching is done
before spinning up TS compiler worker.

Basic dependency tracking for TS compilation has been implemented.

Errors caused by import statements are now annotated with import
location.

Co-authored-by: Ryan Dahl <ry@tinyclouds.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cli related to cli/ dir
Projects
None yet
4 participants