-
Notifications
You must be signed in to change notification settings - Fork 42
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: check assertions per import statement #228
Conversation
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'll review the rest of it later.
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.
Thanks for this @nayeemrmn. It's looking better than main, but I'm not sure about the name "imports". Perhaps this should be something more generic because it also includes exports and typescript path references?
Regarding 2.0 breakages, seems like the only breakage is |
Probably not because merging this would also require more work upgrading the rest of the code in other repos and that would block progress on getting npm specifiers in deno_graph, which is the priority at the moment because we want to get them in a more ideal state for integration with Deploy and other tooling. It's just waiting a couple weeks until early March. |
@dsherret I went ahead and preserved |
With import assertions becoming import attributes and them being part of the cache key, this PR goes in the wrong direction for the future. Closing. |
Closes #132
Fixes #160
Supersedes #155
Assertions appropriately no longer influence module loading/parsing. Instead they are checked in a pass at the end; resulting errors are stored in
Import::errors: Vec<ImportError>
. 'Import errors' are a third kind of error alongside module slot errors and resolution errors which are now checked inModuleEntryIterator::validate()
.