Codecov Report

Attention: Patch coverage is76.99531% with49 lines in your changes missing coverage. Please review.

Project coverage is 50.41%. Comparing base(6ddc2b4) to head(bf0eedc).
Report is 448 commits behind head on main.

@@            Coverage Diff             @@##             main    #3818      +/-   ##==========================================+ Coverage   47.24%   50.41%   +3.16%==========================================  Files         476      460      -16       Lines       46892    45179    -1713     ==========================================+ Hits        22154    22776     +622+ Misses      24738    22403    -2335

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report?Share it here.

I'm trying to think about the implications of always having absolute paths for modules and scripts. Right now, I can think of:

• Users who don't want to use absolute paths on traces for security reasons.
• Users who want to embed Boa in a system that doesn't have a filesystem (not possible now, WIP),
  but that want to expose some relative paths to the host project for debugging purposes.

Committing to absolute paths would be very bad for both use cases.

Maybe we can just change specifiers to store astr, then the loaders would be the ones to decide if they want to parse unix paths/windows paths/urls?

Users who don't want to use absolute paths on traces for security reasons.

Absolute to the root of the (very much virtual) namespace, not their filesystems.Path and FileSystem is an implementation detail. The way to go fromSpecifier toPath is by having a base path, like we do inSimpleModuleLoader. Everywhere else in Boa itself we would never deal with those base paths (which is the part that's sensitive).

Users who want to embed Boa in a system that doesn't have a filesystem (not possible now, WIP), but that want to expose some relative paths to the host project for debugging purposes.

This would be done using theModuleLoader. The base would be the host project, joining specifiers with the base path when loading/resolving modules. The root of the namespace becomes the base of the host project. But that's all up to the host itself, Boa has no knowledge of these kind of details. Boa only cares about specifiers and modules.

Basically what I'm saying is:

Boa SHOULD NOT have as a concern WHERE the file is located or HOW to find it, but that there exists a map of uniqueSpecifier =>Module that can be resolved using aModuleLoader, and that each unique absoluteSpecifier resolves to one and only oneModule.

This is a very powerful statement, and would allow optimizations that are host independent, such as having a module cache outside of module loader, for example.

And to avoid further confusion, what I mean by "absoluteSpecifier" is not absolute in terms of filesystem (Boa should not be aware of filesystems or platform), but in an imaginary namespace that contains all modules handled by the host. Specifier can be seen as URIs in this context, and every module/source would have a Specifier that must be complete (not relative), and every such specifier must point to only one module.

What would be the overall changes toSource if we go with this? Do we need to removeSource::from_filepath and ask users to open the file manually + convert their paths toSpecifier beforehand?
EDIT: Also, can we offer some type of conversion fromPath toSpecifier?

Source::from_filepath would likely take aSpecifier as an additional argument. There is nothing wrong with utility functions. We could also make it separate (aSourceExt trait for example) to keep engine clean, but I don't think that's necessary.

Also, can we offer some type of conversion from Path to Specifier?

Could be inSpecifier itself. There's already afrom_path, all you'd need to do isSpecifier::from_path(path::strip_prefix(base))

This discussion is getting a bit too long for a PR, and I wanted to ask some more questions about the API. I'll open a thread in Matrix.
EDIT: Link to the discussionhttps://matrix.to/#/!hjtiFaaZzLlPqwfAms:matrix.org/$er1XOv9CQIzd2aT2rZfiFAue4zOWBRsDx71XfcOcBtU?via=matrix.org&via=mozilla.org