vuepress build docs get ReferenceError: pageMeta is not defined?

tl;dr You need to downgrade vue-router which is installed as part of vuepress to match ~3.1.3.

I've basically encountered the same error when trying to implement some VuePress theme.

AFAICT the pageMeta is related to VuePress rendering pages on server-side (SSR). It's used in a template using triple curly braces and there are parts of vuepress-generated code assigning data for this markup to be replaced with properly. Since I didn't touch any SSR-related stuff in VuePress I'm quite sure I haven't done anything causing this particular issue explicitly.

So I've tried to disable parts of my code to locate the fragment which is causing this misbehaviour. It turns out the obvious culprit is vue-router.

I'm applying a navigation guard on vue-router instance exposed in enhanceApp.js of VuePress. Inside that guard I put code complying with existing documentation for vue-router. Essentially, I am redirecting some requests due to optionally existing redirection tables or frontmatter information.

In vuepress dev this code is working, but generating errors in browser console. Those errors are about an unhandled promise rejection due to aborting initially requested routing transition in favour of starting another one which seems an eligible intention on using vue-router.

does not work:

export default function( context ) {
    const { router, siteData: { pages, themeConfig = {} } } = context;

    router.beforeEach( handleRedirects );

    function handleRedirects( to, from, next ) {
        const numPages = pages.length;

        for ( let i = 0; i < numPages; i++ ) {
            const { path, frontmatter } = pages[i];

            if ( path === to.path && frontmatter.redirect ) {
                if ( from.path === frontmatter.redirect ) {
                    next( false );
                } else {
                    next( frontmatter.redirect );
                }

                return;
            }
        }

        const redirections = themeConfig.redirect || {};
        if ( redirections.hasOwnProperty( to.path ) ) {
            next( redirections[to.path] );
            return;
        }

        next();
    }
}

does work:

export default function( context ) {
    const { router, siteData: { pages, themeConfig = {} } } = context;

    router.beforeEach( handleRedirects );

    function handleRedirects( to, from, next ) {
        const numPages = pages.length;

        for ( let i = 0; i < numPages; i++ ) {
            const { path, frontmatter } = pages[i];

            if ( path === to.path && frontmatter.redirect ) {
                if ( from.path === frontmatter.redirect ) {
                    next( false );
                } else {
                    next();  // <--- omitting passed target
                }

                return;
            }
        }

        const redirections = themeConfig.redirect || {};
        if ( redirections.hasOwnProperty( to.path ) ) {
            next();    // <--- omitting passed target
            return;
        }

        next();
    }
}

Just to be clear: The latter one makes vuepress build succeed, but the result isn't functional with regards to properly handling redirects.

IMHO the issue is with vue-router for rejecting some promise I didn't start here. One might claim it is with vuepress for failing to adopt a change in API by handling rejected routing transitions properly. But this is also true for SSR (look at third code example given there).

As a solution, you could try downgrading vue-router to versions prior to 3.2.0. In my case, vuepress is properly asking for version ^3.1.3. However, due to semantic versioning, this selector is covering latest 3.4.3 as well.

Thus concluding, there is a breaking change in vue-router, which has been introduced with minor release version 3.2.0. Because of that vue-router isn't complying with semantic versioning.

IMHO, this change of behaviour isn't quite eligible at all for code using vue-router should not have to care about how routing is proceeding unless it leads to some valid target. Thus, code asking to switch route shouldn't cause a rejection that must be handled. This feedback might be optional, but right now it is sort of mandatory.