refactor: check assertions per import statement #228
Conversation
There was a problem hiding this comment.
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().