Here's the function that manages the hooks:

function manageHooks(handler, route, params) {
  if (route && route.hooks && typeof route.hooks === 'object') {
    if (route.hooks.before) {
      route.hooks.before((shouldRoute = true) => {
        if (!shouldRoute) return;
        handler();
        route.hooks.after && route.hooks.after(params);
      }, params);
    } else if (route.hooks.after) {
      handler();
      route.hooks.after && route.hooks.after(params);
    }
    return;
  }
  handler();
};

So, we have if (!shouldRoute) return; which shouldn't allow the routing to happen if you call before hook with a false value. Can you come with a test case that reproduces your situation.

I think the bug is caused in the Navigo.navigate() method in line 186. There you call history api to replace or push new state before calling resolve() in the next line:

navigate: function (path, absolute) {
  var to;

  path = path || '';
  if (this._usePushState) {
    to = (!absolute ? this._getRoot() + '/' : '') + path.replace(/^\/+/, '/');
    to = to.replace(/([^:])(\/{2,})/g, '$1/');
    history[this._paused ? 'replaceState' : 'pushState']({}, '', to); // This causes history modifiaction
    this.resolve(); // manageHooks() method is called in resolve() method. So this is done AFTER history modification
  } else if (typeof window !== 'undefined') {
    path = path.replace(new RegExp('^' + this._hash), '');
    window.location.href =
      window.location.href
        .replace(/#$/, '')
        .replace(new RegExp(this._hash + '.*$'), '') + this._hash + path;
  }
  return this;
}

If think the history modifiaction should be part of the resolve() method and should be suppressed if shouldRoute = false in the manageHooks() method.

Just released 4.7.4. There's no resolve in there anymore. Here's my thinking:

• I agree that the there shouldn't a history entry if shouldRoute = false
• The way of how Navigo works is

       Listening for changes in the URL (1)
--> A change happen via navigate method (2)
       Navigo triggers resolve and checks hooks (3)

Indeed there was a bug. That resolve shouldn't be in the navigate method. It should be called only because the actual path/URL in the browser is changed.

• By design Navigo reacts only on URL changes and I really believe in that.

I see your point and indeed seems logical. However Navigo needs an update in order to continue with resolve and processing hooks. Otherwise it sounds like "Here's the URL that I want to set. Now analyze it, find a match and run the hooks but don't change the URL yet". What I'll suggest is to make your checks before calling navigate on the first place.

@krasimir I'm coming into this late, but hopefully you can answer my question. I was using a version prior to this change that relied on .navigate() to call .resolve().

For this newer version, when I call Navigate and the router is not paused do I need to call .resolve() manually?

I have to routes set up: the root route and ':photo_id'. This sets up the index and the show routes respectively. When I click an image I navigate to :photo_id. In the older version this changed the browser's URL and my callbacks were called because navigate called resolve. Now when I click on the photos the route is changing but my callbacks are not. However, when I click back the routes are resolved.

/
click photo... navigate to /56 (no callbacks) -- I would have expected my callback for /:photo_id to happen here
click photo... navigate to /57 (no callbacks)
click photo... navigate to /58 (no callbacks)
click back (navigates to /57 and callbacks are called)

I'd like to use the newer version so that I could take advantage of the leave hook.

@jgdreyes interesting. Let me investigate. I may introduced a bug with those latest changes.

@jgdreyes sorry for taking so long. Please use 5.0.1 version. it fixes the navigate method. You don't have to call resolve manually.

@krasimir After this issue simple routers do not work (without any hooks) and i should execute resolve manually.

and _onLocationChange never executed for me but location changed

Note that just calling history.pushState() or history.replaceState() won't trigger a popstate event. The popstate event will be triggered by doing a browser action such as a click on the back or forward button (or calling history.back() or history.forward() in JavaScript).

UPD: Sorry, it was with last 4.8 version. With 5.0.2 everything is fine

@VeXell glad that it works. I indeed made a bad release :)