Code Monkey home page Code Monkey logo

route-recognizer's Introduction

Build Status

About

route-recognizer is a lightweight JavaScript library (under 4kB gzipped!) that can be used as the recognizer for a more comprehensive router system (such as router.js).

In keeping with the Unix philosophy, it is a modular library that does one thing and does it well.

Usage

Create a new router:

var router = new RouteRecognizer();

Add a simple new route description:

router.add([{ path: "/posts", handler: handler }]);

Every route can optionally have a name:

router.add([{ path: "/posts", handler: handler }], { as: "routeName"});

The handler is an opaque object with no specific meaning to route-recognizer. A module using route-recognizer could use functions or other objects with domain-specific semantics for what to do with the handler.

A route description can have handlers at various points along the path:

router.add([
  { path: "/admin", handler: admin },
  { path: "/posts", handler: posts }
]);

Recognizing a route will return a list of the handlers and their associated parameters:

var result = router.recognize("/admin/posts");
result === [
  { handler: admin, params: {} },
  { handler: posts, params: {} }
];

Dynamic segments:

router.add([
  { path: "/posts/:id", handler: posts },
  { path: "/comments", handler: comments }
]);

result = router.recognize("/posts/1/comments");
result === [
  { handler: posts, params: { id: "1" } },
  { handler: comments, params: {} }
];

A dynamic segment matches any character but /.

Star segments:

router.add([{ path: "/pages/*path", handler: page }]);

result = router.recognize("/pages/hello/world");
result === [{ handler: page, params: { path: "hello/world" } }];

Sorting

If multiple routes all match a path, route-recognizer will pick the one with the fewest dynamic segments:

router.add([{ path: "/posts/edit", handler: editPost }]);
router.add([{ path: "/posts/:id", handler: showPost }]);
router.add([{ path: "/posts/new", handler: newPost }]);

var result1 = router.recognize("/posts/edit");
result1 === [{ handler: editPost, params: {} }];

var result2 = router.recognize("/posts/1");
result2 === [{ handler: showPost, params: { id: "1" } }];

var result3 = router.recognize("/posts/new");
result3 === [{ handler: newPost, params: {} }];

As you can see, this has the expected result. Explicit static paths match more closely than dynamic paths.

This is also true when comparing star segments and other dynamic segments. The recognizer will prefer fewer star segments and prefer using them for less of the match (and, consequently, using dynamic and static segments for more of the match).

Building / Running Tests

This project uses Ember CLI and Broccoli for building and testing.

Getting Started

Run the following commands to get going:

npm install

Running Tests

Run the following:

npm start

At this point you can navigate to the url specified in the Testem UI (usually http://localhost:7357/). As you change the project the tests will rerun.

Building

npm run build

route-recognizer's People

Contributors

bantic avatar chadhietala avatar danmcclain avatar davidpett avatar dependabot[bot] avatar edazdarevic avatar ember-tomster avatar hjdivad avatar indream avatar jamesplease avatar jayphelps avatar jonasi avatar krisselden avatar lgalfaso avatar locks avatar machty avatar malko avatar mixonic avatar mmun avatar nathanhammond avatar olleolleolle avatar raytiley avatar rwjblue avatar snewcomer avatar spikebrehm avatar stefanpenner avatar trek avatar typicode avatar wagenet avatar wycats avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

route-recognizer's Issues

Cannot parse searchParam that contain `=` in value

recognize ignores search param value after the =. For example this is reported in pretenderjs/pretender#316

let u = new URL('/films?filter=genres=in=(comedy);actor=="Ryan Reynolds"', window.location)
for (let pair of u.searchParams.entries()) {
   console.log(pair[0]+ ', '+ pair[1]);
}

// Browser output: 
// filter, genres=in=(comedy);actor=="Ryan Reynolds"

parseQueryString(queryString: string): QueryParams {
appears to be supporting array syntax but it's something else https://github.com/tildeio/route-recognizer/blob/8e2969be64/tests/recognizer-tests.ts#L794-L803

Notice route-recognizer also does not allow recognizing with searchParams / qp #53.

update / clarify the claim about the <2kB library size in README.md

The very first paragraph of the README.md claims that the size of the route-recognizer library is under 2k:

route-recognizer is a lightweight JavaScript library (under 2k!) that can be used as the recognizer for a more comprehensive router system (such as router.js).

As of 0.3.4 if I create an empty index.js file that only imports the 'route-recognizer' library, the size of output bundle is 13.3kB (minified), and 3.9kB (minified and gzipped). Am I missing something or is the README.me out of date? It looks like README should be saying "(under 4kB gzipped!)".

Steps to reproduce:

  • create a new npm / yarn project:
    mkdir size-control && cd size-control && yarn init
  • add route-recognizer, rollup and uglify-js as dependencies:
    yarn add route-recognizer rollup uglify-js
  • create a main.js file with a single import of 'route-recognizer':
    echo "import RouteRecognizer from './node_modules/route-recognizer/dist/route-recognizer.es.js';" > index.js
  • run rollup to bundle the module into a single file:
    ./node_modules/.bin/rollup index.js -o dist/bundle.js
  • run uglifyjs to minify the bundle:
    ./node_modules/.bin/uglifyjs dist/bundle.js -o dist/bundle.min.js
  • gzip the minified file (OS-dependent):
    gzip dist/bundle.min.js --best -c > dist/bundle.min.js.gz
  • check the size of the bundle: ls -ls dist
-rw-r--r--  1 viktor  staff  22752 Jan 22 11:30 bundle.js
-rw-r--r--  1 viktor  staff  13222 Jan 22 11:31 bundle.min.js
-rw-r--r--  1 viktor  staff   3916 Jan 22 11:32 bundle.min.js.gz

Nested Route Specificity

I did some debugging on an issue I ran into in the Ember app I work on (v2.6.0) after updating the route-recognizer past 0.1.5, in which the specificity of some routes changed. It appears that the specificity of an array of nested routes is only given by the last one.

Here's a test case that passes before and fails after 0499446:

test("Matches the route with the longer static prefix.", function() {
  var handler1 = { handler: 1 };
  var handler2 = { handler: 2 };
  var router = new RouteRecognizer();

  router.add([{ path: "/:dynamic", handler: handler1 }, { path: "/", handler: handler1 }]);
  router.add([{ path: "/static", handler: handler2 }, { path: "/", handler: handler2 }]);

  resultsMatch(router.recognize("/static"), [
    { handler: handler2, params: { }, isDynamic: false },
    { handler: handler2, params: { }, isDynamic: false }
  ]);
});

Is this an expected change, a regression, or something that was never specified? Would love to hear folks' thoughts.

Hi, I'm a member of cdnjs team

Hi, I'm going to host this lib on cdnjs.

But I meet a problem.
I downloaded this lib from npm.
I tried to minify the files in the dist folder.
But I failed.
I try 3 minify tools but still cannot minify it.

Could you help me to minify it?
And if you finish it, please update to npm.
Because we prefer to use npm auto-update.

Thank for your help!
cdnjs/cdnjs#8444

Not preferring fewer dynamic segments

I have a Router with the following routes:

router.map('/').to('index', function(map) {
  map('/commits/*commitish').to('commits', function(map) {
    map('/').to('commit');
    map('/parent').to('commit_parent');
    map('/author').to('commit_author');
  });
});

The reason I'm using *commitish as the ID of the commit is that it can include a forward-slash (e.g. a commit that's pointed to by a tag or branch that has a / in the name).

When I go to /commits/abc123, the router goes through the index, commits, and commit handlers as expected. The commits handler's model hook receives { commitish: "abc123" }.

When I go to /commits/abc123/parent, however, it goes through index, and commits, but the commits handler's model hook receives { commitish: "abc123/parent" } and the commit_parent handler is never triggered.

The Router's docs on the route-recognizer state that it "will prefer routes with fewer dynamic segments, so /posts/edit will match in preference to /posts/:id if both match." This project's own README agrees, but that does not seem to be the case here.

0.1.10 - No source map is available warning

Warning: ignoring input sourcemap for bower_components/route-recognizer/dist/route-recognizer.js because ENOENT: no such file or directory, open '/redacted/tmp/concat_with_maps-input_base_path-QMOFZnGZ.tmp/0/bower_components/route-recognizer/dist/route-recognizer.js.map'

This is exactly like #44 (fixed in 0.1.9) but it is happening again in the latest release 0.1.10.
We started noticing this occurring exactly today. Coincidentally 0.1.10 was published a couple a hours ago that's why we suspect there was a regression.

defining routes bulk and separately

Good day, when I add routes like this, urls not matching:

        router.add([
        { path: "/:lang/wall/posts/:slug", handler: articleController },
        { path: "/:lang/wall/", handler: wallController },
        { path: "/:lang/wall/category/:slug/", handler: wallController },
    ]);

And all fine, when i add them separately:

    router.add([{ path: "/ru/wall/", handler: wallController }]);
    router.add([{ path: "/:lang/wall/category/video", handler: wallController }]);
    router.add([{ path: "/:lang/wall/posts/:slug", handler: articleController }]);

tested urls:
/ru/wall/category/video
/ru/wall/
/ru/wall/posts/na-grebne-volny

Suggestion: removing epsilon segments

As I understand it, epsilon segments were added to support index routes in a library like Router.js. While they do allow us to create that feature, they also bring some issues.

For instance, consider 3 epsilon segments in a row. Is that something worth supporting? I think allowing for epsilon segments means that we must, yet I'm not sure of the utility.

At the moment, epsilon segments are the last thing keeping route-recognizer from having a matching algorithm based solely on specificity and not order added. If you set up a test with 3 epsilon segments, and then a second route with 1 epsilon route, the order that you add them in determines which is matched.

It's probably not impossible to fix this, but is it worth it? If they're only around for index states, then there are more efficient ways to go about adding those in, without any side effects. If multiple epsilon segments is something that Ember wants to support, then there's more work to be done!

I can PR a fix for the sorting issue of epsilon segments, but I think a better idea would be to remove them if they're only around to allow for index states.

Returning the route on recognize?

Is there a good way to get the actual route information back on recognize? I'd like to just define some metadata and use it after it's recognized:

router.add([{ path: "/posts", component: PostComponent, foo: 'bar' }]);

var result = router.recognize("/posts");
// want: result[0].component, etc

I can tack it onto the handler api, but it feels a bit sloppy defining and accessing it through that.

Publish latest version?

route-recognizer has been complaining to ember-cli users forever about an issue that's already been fixed. Could be get a version bump?

Breaks when routes differ only by params

let router = new RouteRecognizer();
router.add([
  { path: '/posts', handler: postsIndex },
  { path: '/posts/:id', handler: postsShow }
]);
router.recognize('/posts') // => undefined
router.recognize('/posts/1') // => undefined

Need a "builds" page

router.js and rsvp.js have pages on S3 that contain recent builds. JSFiddle no longer supports fetching source directly from GitHub (saying, "GitHub isn't a CDN") and this project doesn't have published versions, so it's hard to make a fiddle to show bugs in router.js.

recognize fails with URL-encoded params

Failing test:

test("A dynamic route with encoded params", function() {
  var handler = {};
  var router = new RouteRecognizer();
  router.add([{ path: "/foo/:bar", handler: handler }]);

  // Passes:
  resultsMatch(router.recognize("/foo/bar%20baz"), [{ handler: handler, params: { bar: "bar baz" }, isDynamic: true }]);

  // Fails:
  resultsMatch(router.recognize("/foo/bar%3fbaz"), [{ handler: handler, params: { bar: "bar?baz" }, isDynamic: true }]);

  // Fails:
  resultsMatch(router.recognize("/foo/bar%23baz"), [{ handler: handler, params: { bar: "bar#baz" }, isDynamic: true }]);
});

Use non-matching params as query params?

Hi

I am looking into the following issue of the new angular router (angular/router#176). As I found out, if you want to add query parameters to generate an url, you'll have to add the queryParams property to the params object right?

Isn't it a better approach to take the non-matching segment parameters and use them as query params?

Example

This is how it should be done right now with /user/:id as path.

router.generate('user', {id: 1234, queryParams: {hello: 'world'}});
    // -> /user/1234?hello=world

How it can be done

router.generate('user', {id: 1234, hello: 'world'});
    // -> /user/1234?hello=world

Because hello is not matching a parameter, it will be used as query string parameter.

Which files need to be hosted?

Hi @wycats @stefanpenner @rwjblue ,
We are cdnjs team, we're going to host this library.

cdnjs is one of the most famous free and public web front-end CDN services.

What the files should need to be added in cdnjs?

I know that route-recognizer.js and route-recognizer.js.map and route-recognizer.amd.js@0.1.0 need to be added.
But what about route-recognizer.cjs.js@0.1.0 and after v0.2.9's route-recognizer.es.js and route-recognizer.es.js.map ?
Can these files work on web front-end that CDNJS should host them?

If you have any suggestions, please let me know.

Thank you.

cdnjs/cdnjs#11497
cdnjs/cdnjs#8444
cdnjs/cdnjs#8410

Updated documentation – any interest?

Is there any interest in an update to the docs? I've been going through Route Recognizer to figure out how it works, and I've taken a lot of notes that are neither in the README nor in code comments.

Perhaps the biggest omission from any documentation is the API exposed by the DSL file, which provides Router#map.

Unable to distinguish routes based on different methods/verbs

Since the API only requires path and handler to register a route, there isn't seem to be a way to match a route for a specific verb E.g. get and post might share the same uri structure but a totally different handler.

The work around then is either to have a collection of handlers stored in each route, which can be enumerated after retrieval - which isn't ideal. or to have multiple routers.

Mismatch for nested routes with multiple dynamic segments

I have a use case where I need to match /foo/:bar/baz/:bat while also having /foo/:bar in the list of routes. Currently the recognizer will match /foo/:bar over /foo/:bar/baz/:bat.

I have a failing test case here.

Happy to PR if someone can point me in the general direction of where to get started.

router.recognize() returns Object with Int Indexes rather than an Array!

Hello,

So, i am trying to build an internal routing system, but i am having some problems with the output of the Route-Recognizer after trying to recognize a route.

Right now from the examples, i see that the library should return an array, but where in fact i am getting an Object with Integer Indexes:

RecognizeResults {
  '0': { handler: 'view:admin', params: {}, isDynamic: false },
  '1': { handler: 'view:posts', params: {}, isDynamic: false },
  length: 2,
  queryParams: { key: 'value' } }

Not sure if this is the right behavior. Hopping for some clarifications.

Regards
Sadi

Publish version

Probably worth while releasing the new version with latest changes.

Library does not properly decode dynamic segment from utf-8 route

this.route('worker', {
  path: 'praca-sprzątanie'
}, function () {
  this.route('city', {
    path: 'kczewo'
  });
});

When going on praca-sprzątanie/kczewo, route is properly recognized but dynamic segement is passed down as null. Code does behave correctly with ENCODE_AND_DECODE_PATH_SEGMENTS turned off.

image
image
image

Problem comes down to fact that originalPath is not decoded anyhow but later on it's used inside regular expression.

Is there any way to overwrite ENCODE_AND_DECODE_PATH_SEGMENTS flag from ember application till the issue will be resolved?

Issue was observed on ember 3.4.0

Clobbering inside of `names` object.

router.add([{ path: "/posts/:id/foo", handler: "post" }], { as: "post" });
router.add([{ path: "/posts/:id", handler: "post" }], { as: "post" });

This puts two routes into the NFA and one route into the names object by virtue of clobbering. Lookup by name will thus return the second route. However, router.recognize('/posts/12/foo') will still actually match and return the handler specified for the first route as it still exists in the NFA.

We should stop allowing you to clobber keys in the names object.

@wycats @rwjblue @krisselden @mixonic Confirm that this should be considered a bug?

/cc @trentmwillis

Optional Route Segments

Problem

For localization it's common with an URL structure like this:

/
/about/
/pricing/
…

/de/
/de/about/
/de/pricing/
…

/es/
/es/about/
/es/pricing/
…

Optional segments like this doesn't seem to be supported by the route recognizer, making it difficult to use Ember for any localized website.

Desired outcome

router.add([
  { path: "/:locale/", handler: mother },
]);

let result1 = router.recognize("/es/about");
result1 === [
  { handler: mother, params: { locale: 'es' } },
  { handler: about, params: {} }
];

let result2 = router.recognize("/about");
result2 === [
  { handler: mother, params: { locale: null } },
  { handler: about, params: {} }
];

Workarounds

For Ember apps, the specific case of a language prefix can be solved by using a custom location class, that will extract/inject any language prefix before passing the URL along to the underlying location implementation.

https://api.emberjs.com/ember/release/classes/Location

Prior Art

Related RFCs

This has been proposed in emberjs/rfcs#154, though that proposal include other changes too. Also, I'm unsure about whether this should go into the route recognizer (I think so) or in software consuming this library (not so sure).

Relevant and semi-relevant threads online

https://stackoverflow.com/questions/26871152/ember-optional-url-segments
https://stackoverflow.com/questions/44272568/how-to-make-route-parameters-optional-in-ember-js
https://discuss.emberjs.com/t/dynamic-segments-optional/15699
https://stackoverflow.com/questions/19991135/ember-js-define-route-with-optional-parameter-and-default-model/27187769
https://discuss.emberjs.com/t/is-there-really-no-way-to-make-an-optional-dynamic-segment-in-ember/5010/8

query support

Hi, is there any support for things like url.com/path?query=23&other_query=423?

thanks

Several routes consuming epsilon segments are now disallowed

I found this problem after upgrading to Ember 2.10, but it's probably related with the changes in RR.

Assume the following routes:

Router.map(function() {
  this.route('authenticated', { path: '/' }, function() {
    this.route('foo');
    this.route('bar');
  });
  this.route('landing-page', { path: '' });
});

In 2.9, visiting / rendered the landing-page route. In 2.10, an error about defining the application route twice is displayed.

Twidded demostrating the issue: https://ember-twiddle.com/630dfff296ebe1ffdb18eff18b1a9894?openFiles=router.js%2C

Toggle ember's version between 2.9 and 2.10 to see app work/fail.

Suggestion: Improve performance through regex memoization

Hey! Recently I've started to hit some performance bottlenecks that seem to be stemming at least partially from route-recognizer. It might be the case that the root of the issue is due to either 1) My application being too large, or 2) ember-source not using the recognizer in the most optimal way, so take whatever I suggest with a grain of salt.

I ran some performance checks when running an acceptance test in Ember. This test loads up all of our routes (we have a lot) at the beginning of the test, and it takes a significant chunk of time. Around 20%.

image

While I do think there could be some optimization elsewhere - it seems like an easy improvement might be to include some memoization for the regex functions in route-recognizer? I could be overlooking some possible downsides here, and I'm not super familiar with this library. Does this seem like a reasonable suggestion?

I did some testing with a local fork and it seemed to have significant improvements on my test execution time. FWIW if this suggestion gets any traction, I'm happy to do the work to implement it.

Wrong route priority with asterisk match

Originally filed at emberjs/ember.js#10025.

I've came across a potential bug in the router. Given the following map definition:

App.Router.map(function() {
  this.route('search', { path: '/search/*phrase' });
  this.route('other', { path: '/:foo/:bar' });
});

it's impossible to reach search route when entering through /search/a-search-phrase URL. Here is a jsbin demonstrating this: http://emberjs.jsbin.com/waxovu/1/edit?html,js,console,output and here is what happens when you try to enter search route: http://emberjs.jsbin.com/waxovu/1#/search/something. If you enter this URL, you should see Other template: {"foo":"search","bar":"something"}. Links correctly transition to both routes.

It seems that the problem is caused by the sortSolutions function in route-recognizer. A comment on top of the function mentions what's a general strategy, but there is no mention what's the purpose of this in the first place. My first intuition when using router was that routes priority is based on the order of adding them, so such a router:

Router.map(function() {
  this.route('search', { path: '/search/*phrase' });
  this.route('repo', { path: '/:owner/:name' });
});

would match the search route first and then repo route if search was not matched.

I think that such a behaviour is easier to document and easier to predict for a developer. I suppose changing that in 1.x release is a no-go for backwards compatibility, but maybe it could be addressed in 2.0?

Match any domain

Currently it's not possible to match a uri on anydoman
For example, http://mysite.com/download and http://localhost/download can be matched by **/download using minimatch. They call it "Globstar".
Are you planning to introduce something similar?

Star routes seem to get priority over other routes which have trailing '/'

Original issue in Ember: emberjs/ember.js#13211

I have a failing test for route-recognizer, I'll open a PR in just a moment. There is an ember working demo on the original issue.

I don't yet fully understand the mechanics of route-recognizer, but it seems that starting with 0.1.6 (and later) when you have a route that has just a trailing '/' as it's path, star routes end up prioritized over it. For example:

router.add([
  { path: "/foo/:dynamic", handler: handler1 }, 
  { path: "/baz/:dynamic", handler: handler2 }, 
  { path: "/", handler: handler3 }
]);
router.add([
  { path: "/foo/:dynamic", handler: handler1 }, 
  { path: "/*wildcard", handler: handlerWildcard }
]);

// Returns the `/*wildcard` route, rather than the above route.
router.recognize("/foo/r3/baz/w10"); 

Edit: Failing Test: #83

Dynamic segments include extention

When defining a dynamic route with an extension, such as /users/:id.json, route-recognizer considers :id.json a dynamic segment, when it should consider :id the dynamic segment.

When resolving the aforementioned example (/users/:id.json), with /users/1.json, the recognized params are: "params": { "id.json": "1.json" }. I expected them to be "params": { "id": "1" }.

I found this issue through ember-cli-mirage. While my ember app does not include extensions like this, my API does.

Here is an example twiddle demonstrating the issue: https://ember-twiddle.com/5bbd4af2a97afe54b6fe6833ad0a1758?numColumns=2&openFiles=mirage.config.js%2Cadapters.user.js

I am currently working on a PR to resolve this, but wanted to open the issue to document process, and also to double check that this is not intentional.

UPDATE: This test demonstrates my issue ActionSprout@95ec725.

Recognizing routes with queryParams

Hi, over at @stackbuilders/all we're using route-recognizer as part of pretender.js to test an Ember app.

We have a complex scenario we're we are calling a backend endpoint with different query params to get a filtered collection of items leaving us with very complex test code where we map the params to what the responses should be.

From looking at the code of the library you guys are already adding the endpoint with the query params but when recognizing it you guys are dropping the query params leaving the recognize without viable solutions because it can't find any handlers for the route without the query params

Is this the intended behaviour, would making a patch for it to match the url with the queryParams make sense to you?

EDIT: Updated the code references to v0.1.9 which was the version used at the time I reported this.

Optional dynamic segments

In tildeio/router.js#102, @mgenev expressed his frustration for dealing with a complex routing situation that he believed optional dynamic segments would resolve. @machty said he would support this were a PR made here in route-recognizer, so I'm creating this issue to document it as a todo.

Prior art:

Backbone

Optional segments are wrapped in parentheses. i.e. docs/:section(/:subsection)

React Router

A question mark marks the previous segment as optional. i.e. docs/:section?

However, React is apparently switching over to parentheses because of how annoying it is to deal with the question marks (ref: remix-run/react-router#960 )

TypeScript declaration is wrong in CommonJS

The .d.ts file exports a default class, which makes TypeScript look for a .default property on the exports object in CommonJS. However, in CommonJS environments, the exports object is set to the class itself. This makes it unusable in Node.js/TypeScript projects.

Build is not failing on TypeScript errors

I would assume that running ember build would fail when I create a type error like changing the return type of normalizePath() to boolean instead of string.

I'm seeing the following output:

/route-recognizer.ts(633,7): Type 'boolean' is not assignable to type 'string'.
/route-recognizer/normalizer.ts(6,10): Type 'string' is not assignable to type 'boolean'.

but the build still succeeds with exit code 0.

/cc @stefanpenner @rwjblue @nathanhammond @krisselden

Building route-recognizer for non-Ember projects

Hi, I'm working on a non-Ember project (React/Redux, built with Webpack) and tried importing route-recognizer with no success. Is this library meant for use in non-Ember projects?

Here's what I did:
I ran npm install route-recognizer which gave me version 0.3.0. I then tried to import RouteRecognizer from 'route-recognizer'; and the module wasn't found. The package.json file contains the following: "main": "dist/route-recognizer.js" and it looks like that file doesn't exist. The dist folder contains route-recognizer, route-recognizer.d.ts, route-recognizer.es.js, and route-recognizer.es.js.map.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.