You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are currently three choices that I come up with (they are either from the standard library or are used by SWC which will not increase the size of our binary):
canonicalize in the standard library absolutizes relative paths. It requires file system access, resolves symbolic links, and returns verbatim paths (prefixed by \\?\) for Windows.
normpath introduces BasePath that is an improved version of Path in the standard library. For instance, join intends to normalize . and .. without requiring file system access. Its normalize method is the same as canonicalize on Unix.
path_clean is an extremely small crate that provides only one method: clean. It simply cleans up . and .. without accessing the file system (thus works regardless of whether the path exists). It works for both relative and absolute paths and does not normalize relative paths into absolute (because it performs only lexical processing).
My plan is as follows:
Within the bundler: SWC performs canonicalization on Windows in the first place (turning into verbatim path). However, we have access to the absolute base path in the path resolver, so we really just need path_clean to clean up . and ...
Other places: I'm not sure if we care about any paths other than app_data_dir. From this Discord discussion it seems that this is the defacto standard, and app_data_dir is given as an absolute path (non-verbatim). Thus, I don't think we ever need to absolutize a path (thus canonicalize and normpath are not needed), and path_clean would be sufficient.
Hence the principle is that we never use canonicalize (otherwise we will mess up verbatim and non-verbatim paths on Windows), and we do not need any external crate other than path_clean: there is no need to absolutize a relative path because we can simply join and clean given access to the absolute base directory, and path_clean will give us consistent paths when we need to make comparison.
Canonicalization may still be used in tests because we have functions that expect absolute paths as inputs.
Looking for opinions from @CSCI-SHU-410-SE-Project/core-dev :)
The text was updated successfully, but these errors were encountered:
There are currently three choices that I come up with (they are either from the standard library or are used by SWC which will not increase the size of our binary):
canonicalize
in the standard library absolutizes relative paths. It requires file system access, resolves symbolic links, and returns verbatim paths (prefixed by\\?\
) for Windows.normpath
introducesBasePath
that is an improved version ofPath
in the standard library. For instance,join
intends to normalize.
and..
without requiring file system access. Itsnormalize
method is the same ascanonicalize
on Unix.path_clean
is an extremely small crate that provides only one method:clean
. It simply cleans up.
and..
without accessing the file system (thus works regardless of whether the path exists). It works for both relative and absolute paths and does not normalize relative paths into absolute (because it performs only lexical processing).My plan is as follows:
path_clean
to clean up.
and..
.app_data_dir
. From this Discord discussion it seems that this is the defacto standard, andapp_data_dir
is given as an absolute path (non-verbatim). Thus, I don't think we ever need to absolutize a path (thuscanonicalize
andnormpath
are not needed), andpath_clean
would be sufficient.Hence the principle is that we never use
canonicalize
(otherwise we will mess up verbatim and non-verbatim paths on Windows), and we do not need any external crate other thanpath_clean
: there is no need to absolutize a relative path because we can simplyjoin
andclean
given access to the absolute base directory, andpath_clean
will give us consistent paths when we need to make comparison.Canonicalization may still be used in tests because we have functions that expect absolute paths as inputs.
Looking for opinions from @CSCI-SHU-410-SE-Project/core-dev :)
The text was updated successfully, but these errors were encountered: