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

feat(unstable): fast subset type checking of JSR dependencies #21873

Merged
merged 40 commits into from
Jan 10, 2024

Conversation

dsherret
Copy link
Member

@dsherret dsherret commented Jan 9, 2024

Integrates denoland/deno_graph#346 ("fast check")

This leads to a major speedup of type checking of remote JSR dependencies in Deno that are distributed as TypeScript by only providing TypeScript with the code relevant to the public API of dependencies.

Performance Improvement Example

// main.ts
import $ from "jsr:@dsherret/dax";
console.log($);

Before (no check cache):

> rm C:\Users\david\AppData\Local\deno\check_cache_v1 ; Measure-Command { deno check --all main.ts }
        1266.3429ms

After (no check cache):

> rm C:\Users\david\AppData\Local\deno\check_cache_v1 ; Measure-Command { ../deno/target/release/deno check --all main.ts } 
         590.5861ms

How this works

  1. The public API is determined via a Rust-based TypeScript symbol graph built on top of swc.
  2. The TypeScript source is then transformed to remove parts that are not relevant for the remote module being used as a dependency.
  3. The transformed source is internally stored along with its source map for mapping diagnostic positions.
  4. In the future, we'll cache this information so we don't need to recompute it (this is not implemented atm).

If the public API or a type in the public API cannot be determined, then it falls back to not using this feature and instead uses the full TypeScript sources.

Since this is something hidden away in the runtime, we can drop this feature at any time or provide overrides to disable it.

This feature is not implemented in the LSP atm, but in that case it would expand to the full source once opening a remote dependency (ex. doing "go to definition" on a symbol that ends up in a remote dep), but otherwise it would use the subset.

Example

Given the following source:

// https://.../package/mod.ts
import path from "jsr:@std/path";

export function join(a: string, b: string): string {
  console.log(a, b);
  return path.join(a, b);
}

function notUsed() {
  return Math.random();
}

We can strip out the non-relevant parts and end up with the following for type checking purposes:

export function join(a: string, b: string): string {
  return {} as any;
}

Why not transform to a declaration file?

  1. There's no need and this way allows us to rely on TypeScript's inference in certain cases, especially in cases when TypeScript is going to be fast at inferring.
  2. The semantics of declaration files are slightly different.
  3. This keeps the specifier the same. We don't need to create some fake .d.ts file.

What about globals?

Globals can be defined in any file in TypeScript and if someone defined a global deep in their dependency then this wouldn't work. In this case, this feature only applies to JSR dependencies and we currently do not allow globals being defined in JSR deps. In the future we'll look at relaxing this restriction to likely require defining globals in a certain place. That would allow this to quickly check for globals there and maintain that code.

.default_missing_value(".")
.value_hint(ValueHint::DirPath)
.required(true),
)
Copy link
Member Author

Choose a reason for hiding this comment

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

Removed for now because it was broken. A lot of our code currently resolves stuff like the config file being resolved based on the cwd.

Copy link
Member

Choose a reason for hiding this comment

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

After some consideration I think we really need to have this soon - maybe as a quick-fix we could spawn subprocess in the correct CWD to it working that way?

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 seems easy to just do (cd some_dir && deno publish)? Most people will be publishing from the directory they're in.

Copy link
Member

Choose a reason for hiding this comment

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

I don't think I even used it in a CWD, not a big deal though. We can address it in a follow up

Copy link
Member

Choose a reason for hiding this comment

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

If you remove this, you can’t publish single modules in a workspace anymore. That seems annoying

Copy link
Member Author

@dsherret dsherret Jan 10, 2024

Choose a reason for hiding this comment

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

You can by not publishing from the root (instead you publish in the dir of the package)

Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

@dsherret But this doesn't work if you have two deno.json (workspace level and package level), and you have import maps in both, and your package requires an import map entry from the workspace level one.

Copy link
Member Author

@dsherret dsherret Jan 12, 2024

Choose a reason for hiding this comment

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

@lucacasonato if it doesn't then that's a bug there (not a limitation with not being able to provide a publish directory)

.default_missing_value(".")
.value_hint(ValueHint::DirPath)
.required(true),
)
Copy link
Member

Choose a reason for hiding this comment

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

After some consideration I think we really need to have this soon - maybe as a quick-fix we could spawn subprocess in the correct CWD to it working that way?

Comment on lines 13 to 16
// this won't be type checked against because the subset
// type graph will ignore it
const invalidTypeCheck: number = "";
console.log(invalidTypeCheck);
Copy link
Member

@bartlomieju bartlomieju Jan 10, 2024

Choose a reason for hiding this comment

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

Could you describe the reason for different behavior between this...

Copy link
Member Author

Choose a reason for hiding this comment

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

I updated the comments for these. Let me know if the new comments don't explain it well enough.

Copy link
Member

Choose a reason for hiding this comment

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

That's good, thanks!

Comment on lines 7 to 10
// this will be analyzed because the method above is missing an
// explicit type which is required for the subset type graph
const invalidTypeCheck: number = "";
console.log(invalidTypeCheck);
Copy link
Member

Choose a reason for hiding this comment

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

...and this?

Comment on lines +297 to +301
// todo(dsherret): use a short lived cache to prevent parsing
// source maps so often
if let Ok(source_map) =
SourceMap::from_slice(&fast_check_module.source_map)
{
Copy link
Member

Choose a reason for hiding this comment

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

Could you do it in this PR by adding a cache in apply_fast_check_source_map? Or do you feel it's not gonna have much impact without it for now?

Copy link
Member Author

Choose a reason for hiding this comment

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

I opened #21877

@@ -586,7 +590,7 @@ fn op_resolve(
let resolved_dep = graph
.get(&referrer)
.and_then(|m| m.esm())
.and_then(|m| m.dependencies.get(&specifier))
Copy link
Member

Choose a reason for hiding this comment

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

Does this line applies fast check for all type checking in the CLI?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, only if it appears in the graph.

Copy link
Member

Choose a reason for hiding this comment

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

Wow, positively surprising that no other test failed!

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 internally does if let Some(module) = &self.fast_check { &module.dependencies } else { &self.dependencies }.

.default_missing_value(".")
.value_hint(ValueHint::DirPath)
.required(true),
)
Copy link
Member

Choose a reason for hiding this comment

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

I don't think I even used it in a CWD, not a big deal though. We can address it in a follow up

@@ -586,7 +590,7 @@ fn op_resolve(
let resolved_dep = graph
.get(&referrer)
.and_then(|m| m.esm())
.and_then(|m| m.dependencies.get(&specifier))
Copy link
Member

Choose a reason for hiding this comment

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

Wow, positively surprising that no other test failed!

Copy link
Collaborator

@nayeemrmn nayeemrmn left a comment

Choose a reason for hiding this comment

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

LGTM

@dsherret dsherret enabled auto-merge (squash) January 10, 2024 22:15
@dsherret dsherret merged commit 70ac061 into denoland:main Jan 10, 2024
14 checks passed
@dsherret dsherret deleted the low_res_type_checking branch January 10, 2024 22:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants