I have a shared library that's used by both client-side and server-side scripts. I needed to use N/cache in it, but importing it at the top level caused errors on the client side since that API is only supported in server scripts. The logic in the library is quite complex, so splitting it wasn't really practical. As a workaround, I moved the N/cache import inside a function so it only gets loaded when actually needed. This avoids the client-side error while still letting me use the module on the server side. any drawback of this approach? (ErrorUtils.js uses n/cache) sample code below:

define([], function () {
function clientfunc(){}
    function pushErrorToCache(errorObj) {
        // Lazy load to avoid client-side errors
        require(['./ErrorUtils'], function (ErrorLogger) {
            ErrorLogger.pushErrorToCache(errorObj);
        });
    }

    function newfunctionusingcache(rec, fieldId, value) {
        try {
           
        } catch (e) {
            const errorObj = {
                fieldId,
                value,
                message: e.message
            };
            pushErrorToCache(errorObj);
        }
    }

    return {
        newfunctionusingcache,clientfunc
    };
});

I've never thought about doing it this way but if it works it works. The "typical" way would be to do what you described and break it out to a server-side and a client-side library. I def wish that the server-side libraries would just be ignored if being loaded client-side but it is what it is.

You could also

require

N/cache itself.

Yes, I can

require

the cache in the same file, but since "errorutil" contains a lot of other logic, moved there

I mean using require with cache in your errorLib

let cache;
try {
    if (runtime.executionContext !== runtime.ContextType.CLIENT && runtime.executionContext !== runtime.ContextType.USER_INTERFACE) {
        require(['N/cache'],  (c) => {cache = c});
    }
} catch (e) {
    cache = null; 
}

now I got it, thankyou 🙂

neat approach, never thought to do this, I just put cache in its own lib file when I've ran into this.... are there other server side modules this happens with I've only ever ran into this issue with cache?

N/file is another

right, I was ware of that too, but I'd never think to put file client side, cos I know I have to call a suitelet to do file operations from the client... or i guess I should say I'd avoid putting file code in a library in the first place

I have run into this in the past and I just made separate libraries. The one that is compatible with both is included in the one that just adds caching and so it's called from server side scripts and then client side scripts call the one without. That way the shared functions are still in the one that has cross compatibility so there is no duplicate code. It's still an interesting solution I will be definitely tempted to use.

I would suggest considering refactoring the caching such that if it's a client script you use browser based caching, server script use N/cache. That way you'd preserve the functionality of caching on both sides.

I don’t need the caching logic on the client scripts at all. i had this workaround only because the same library file is used by both the client and the server and i cannot split the library file easily.