Turn a path string such as `/user/:name` into a regular expression
MIT License
Bot releases are visible (Hide)
Published by blakeembrey about 1 month ago
Added
match
and pathToRegexp
3fdd88fhttps://github.com/pillarjs/path-to-regexp/compare/v7.1.0...v7.2.0
Published by blakeembrey about 1 month ago
Added
pathToRegexp
method back for generating a regexstringify
method for converting TokenData
into a path stringhttps://github.com/pillarjs/path-to-regexp/compare/v8.0.0...v8.1.0
Published by blakeembrey about 2 months ago
Heads up! This is a fairly large change (again) and I need to apologize in advance. If I foresaw what this version would have ended up being I would not have released version 7. A longer blog post and explanation will be incoming this week, but the pivot has been due to work on Express.js v5 and this will the finalized syntax used in Express moving forward.
Added
*name
syntax, aligns with :
behavior but using an asterisk insteadChanged
?
, +
, and *
- only optional exists moving forward (use wildcards for +
, {*foo}
for *
)Added
:"foo-bar"
string | TokenData | Array<string | TokenData>
Removed
loose
modehttps://github.com/pillarjs/path-to-regexp/compare/v7.1.0...v8.0.0
Published by blakeembrey about 2 months ago
Fixed
https://github.com/pillarjs/path-to-regexp/compare/v0.1.9...v0.1.10
Published by blakeembrey about 2 months ago
Added
https://github.com/component/path-to-regexp/compare/v0.1.8...v0.1.9
Added
strict
option to detect potential ReDOS issuesFixed
suffix + prefix
when not specifiedTokenData
TokenData
manually, previously parse
filled it in automaticallyComments
strict: true
and I'm probably releasing a V8 with it enabled by default ASAP as a necessary security mitigationhttps://github.com/pillarjs/path-to-regexp/compare/v7.0.0...v7.1.0
Published by blakeembrey 4 months ago
Hi all! There's a few major breaking changes in this release so read carefully.
Breaking changes:
compile
only accepts strings as values (i.e. no numbers, use String(value)
before compiling a path)
encode !== false
, it must be an array of strings\p{XID_Continue}
).?
, *
, +
) must be used after a param explicitly wrapped in {}
/
or .
*
) has been added back and matches Express.js expected behaviorendsWith
optionstrict: true
to trailing: false
;
, ,
, !
, and @
for future use-casestokensToRegexp
, tokensToFunction
and regexpToFunction
in favor of simplifying exports/
can be repeated multiple times in a matched path (i.e. /foo
works like //foo
, etc)encode
and decode
no longer receive the token as the second parameterencodeURIComponent
and decode defaults to decodeURIComponent
Added:
encodePath
to fix an issue around encode
being used for both path and parameters (the path and parameter should be encoded slightly differently)loose
as an option to support arbitrarily matching the delimiter in paths, e.g. foo/bar
and foo///bar
should work the sameencode
and decode
to be set to false
which skips all processing of the parameters input/outputTokenData
(exported, returned by parse
) as input
Requests for feedback:
{}
is an obvious drawback but I'm seeking feedback on whether it helps make path behavior clearer
/
and .
as implicit prefixeshttps://github.com/pillarjs/path-to-regexp/compare/v6.2.2...v7.0.0
Published by blakeembrey 7 months ago
No API changes. Documentation only release.
Changed
https://github.com/pillarjs/path-to-regexp/compare/v6.2.1...v6.2.2
Published by blakeembrey 7 months ago
Added
https://github.com/pillarjs/path-to-regexp/compare/v0.1.7...v0.1.8
Published by blakeembrey over 2 years ago
Fixed
:name*
parameter (#261) 762bc6bAdded
https://github.com/pillarjs/path-to-regexp/compare/v6.2.0...v6.2.1
Published by blakeembrey about 4 years ago
Added
Fixed
strict
flag documentation (#227)Published by blakeembrey almost 5 years ago
Fixed
/#?
as default delimiter to avoid matching on query or fragment parameters
delimiter: '.'
Published by blakeembrey almost 5 years ago
Note: The path syntax has been stabilized with this release, no breaking changes in paths is expected.
This release reverts the prefix behavior added in v3 back to the behavior seen in v2. For the most part, path matching is backward compatible with v2 with these enhancements:
/(abc(?=d))
/{abc(.*)def}
/test(foo
previously worked treating (
as a literal character, now it expects (
to be closed and is treated as a group/test\(foo
Changed
prefixes
option to configure this (starts as /.
which acts like every version since 0.x again){}
to capture prefix/suffix explicitly, enables custom use-cases like /:attr1{-:attr2}?
Published by blakeembrey almost 5 years ago
No changes to path rules since 3.x, except support for nested RegEx parts in 4.x.
Changed
RegexpOptions
interface to TokensToRegexpOptions
normalizePathname
from library, document solution in READMEencodeURIComponent
Published by blakeembrey almost 5 years ago
Removed
whitelist
in favor of decodeURI
(advanced behavior can happen outside path-to-regexp
)Published by blakeembrey almost 5 years ago
Fixed
String.prototype.normalize
to continue supporting IEPublished by blakeembrey almost 5 years ago
Added
/%.-
)Published by blakeembrey almost 5 years ago
Fixed
RegexpOptions
in match(...)
functionPublished by blakeembrey almost 5 years ago
Fixed
regexp
spelling across 4.xPublished by blakeembrey almost 5 years ago
All path rules are backward compatible with 3.x, except for nested ()
and other RegEx special characters that were previously ignored.
Changed
match
does not default to decodeURIComponent
Added
normalizePathname
utility for supporting unicode paths in libraries