-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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: new module graph used for no check #7621
Conversation
bfeb062
to
93bef65
Compare
Does this mean there will be two module graphs? This patch is a rather large net addition of code, so it needs to be carefully considered before landing. |
Yes, two module graph for a small period of time as we transition, as a total refactor was considered a bad idea. I tried other ways of swallowing the elephant, and this was the best I could come up with. Expand and then contract... At the end of the journey, it will result in thousands of lines of less code. |
Just to give an idea of the long term roadmap, is something like this:
I suspect I need to add about ~500 lines to the new graph.rs to facilitate the rest of it. So in the end a savings of about 3k of code. |
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! Just a few minor comments. I understand that this is transitive state before complete cleanup so I don't mind additional code for a few days.
} | ||
|
||
#[derive(Clone, Debug, PartialEq)] | ||
pub struct Stats(Vec<(String, u128)>); |
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.
Use type alias instead? That way there will be no need for custom Deserialize
implementation
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've got a custom fmt:Display
as well. It is nice to have it all be self contained, IMO.
5a851d2
to
ea466d2
Compare
@bartlomieju addressed your feedback, PTAL. |
@kitsonk LGTM |
) I'm unsure why we canonicalize the config file path when loading and the canonicalization is causing issues in #19431 because everything in the lsp is not canonicalized except the config file (actually, the config file is only canonicalized when auto-discovered and not whens pecified). We also don't canonicalize module paths when loading them. Canonicalization was added in #7621
) I'm unsure why we canonicalize the config file path when loading and the canonicalization is causing issues in #19431 because everything in the lsp is not canonicalized except the config file (actually, the config file is only canonicalized when auto-discovered and not whens pecified). We also don't canonicalize module paths when loading them. Canonicalization was added in #7621
This PR is part of #7225 and introduces a new module graph that is more fit for purpose for how Deno handles code and dependencies. Because the refactor will take a while to do and we don't want huge PR, the first step is to utilise the module graph to do the
--no-check
transpile only.This makes the whole API far more easier to understand what is going on, and makes it overall more maintainable. A simplified version of doing the transpile now looks like this:
The module graph becomes the "controller" which orchestrates fetching modules, doing dependency analysis, and reading and writing to the disk cache.
Things to do on this PR: