A comprehensive, cross-platform path manipulation library for Dart.
The path package provides common operations for manipulating paths: joining, splitting, normalizing, etc.
We've tried very hard to make this library do the "right" thing on whatever
platform you run it on, including in the browser. When you use the top-level
functions, it will assume the current platform's path style and work with
that. If you want to explicitly work with paths of a specific style, you can
path.Context for that style.
The path library was designed to be imported with a prefix, though you don't have to if you don't want to:
import 'package:path/path.dart' as path;
The most common way to use the library is through the top-level functions. These manipulate path strings based on your current working directory and the path style (POSIX, Windows, or URLs) of the host platform. For example:
This calls the top-level [join] function to join "directory" and "file.txt" using the current platform's directory separator.
If you want to work with paths for a specific platform regardless of the underlying platform that the program is running on, you can create a [Context] and give it an explicit [Style]:
var context = new path.Context(style: Style.windows); context.join("directory", "file.txt");
This will join "directory" and "file.txt" using the Windows path separator, even when the program is run on a POSIX machine.
Pathos runs on the Dart VM and in the browser under both dart2js and Dartium. Under dart2js, it currently returns "." as the current working directory, while under Dartium it returns the current URL.
When you have path objects, then every API that takes a path has to decide if it accepts strings, path objects, or both.
Accepting strings is the most convenient, but then it seems weird to have
these path objects that aren't actually accepted by anything that needs a
path. Once you've created a path, you have to always call
it before you can do anything useful with it.
Requiring objects forces users to wrap path strings in these objects, which is tedious. It also means coupling that API to whatever library defines this path class. If there are multiple "path" libraries that each define their own path types, then any library that works with paths has to pick which one it uses.
Taking both means you can't type your API. That defeats the purpose of having a path type: why have a type if your APIs can't annotate that they expect it?
Given that, we've decided this library should simply treat paths as strings.
We believe this library handles most of the corner cases of Windows paths (POSIX paths are generally pretty straightforward):
It understands that both "/" and "" are valid path separators, not just "".
It can accurately tell if a path is absolute based on drive-letters or UNC prefix.
It understands that "/foo" is not an absolute path on Windows.
It knows that "C:\foo\one.txt" and "c:/foo\two.txt" are two files in the same directory.
If you use this package in a browser, then it considers the "platform" to be the browser itself and uses URL strings to represent "browser paths".
canonicalize() top-level functions and
Context methods. These make it easier to treat paths as map keys.
Properly compare Windows paths case-insensitively.
Further improve the performance of
isWithin()when paths contain
/.sequences that aren't
Improve the performance of
isWithin() when the paths don't contain
Improve the performance of
null and the path is
Improve the performance of
current when the current directory hasn't
path.toUripreserves trailing slashes for relative paths.
Context.relative- don't call
fromis not relative.
contextfield that provides access to a
Contextobject for the current system.
Many members on
Style that provided access to patterns and functions used
internally for parsing paths have been deprecated.
Manually parse paths (rather than using RegExps to do so) for better performance.
path.prettyUri, which produces a human-readable representation of a URI.
path.fromUrinow accepts strings as well as
Add this to your package's pubspec.yaml file:
dependencies: path: "^1.4.0"
You can install packages from the command line:
$ pub get
$ flutter packages get
Alternatively, your editor might support
pub get or
Check the docs for your editor to learn more.
Now in your Dart code, you can use:
|1.5.1||Nov 21, 2017|
|1.5.0||Nov 7, 2017|
|1.4.2||Jun 8, 2017|
|1.4.1||Dec 8, 2016|
|1.4.0||Oct 10, 2016|
|1.3.9||Dec 2, 2015|
|1.3.8||Dec 1, 2015|
|1.3.7||Nov 18, 2015|
|1.3.6||Jul 9, 2015|
|1.3.5||Apr 9, 2015|
We analyzed this package on Mar 5, 2018, and provided a score, details, and suggestions below. Analysis was completed with status completed using:
Describes how popular the package is relative to other packages. [more]
Code health derived from static analysis. [more]
Reflects how tidy and up-to-date the package is. [more]
Weighted score of the above. [more]
Detected platforms: Flutter, web, other
No platform restriction found in primary library
Maintain an example.
Create a short demo in the
example/directory to show how to use this package. Common file name patterns include:
example.dartor you could also use
Fix issues reported by
dartfmtreported 5 hints.
Similar analysis of the following files failed:
|Dart SDK||>=1.0.0 <2.0.0|