Partner Workspace limitation: Internal Script Packages not allowed

Help Hub
1

Hi everyone,

After converting our Internal Workspace into a Partner Workspace, we lost access to our Private Script Packages.
Our internal packages contained shared logic that used pm.* functions (pm.sendRequest, pm.headers, etc.) across multiple collections.

I’ve already tested one workaround — storing all shared functions as a single global variable and injecting them at runtime via:

eval(pm.globals.get("sharedUtils"));

It works, but it feels like a hack and lacks versioning, linting, and safety.

So my question is:

  1. Are there any official or recommended ways to share and reuse Postman scripts that depend on pm.* inside a Partner Workspace?
  2. Can npm/JRM packages somehow access or receive the pm context at runtime?
  3. Are there any planned features or best practices for script reusability in this scenario (similar to the deprecated private Script Packages)?

Any advice or guidance from the Postman team or other users who faced this would be very helpful.

Thanks in advance!

1 Like
2

Hey @devdeer-andrii :waving_hand:

I’m just jumping in here to let you know that someone has seen this so you’re not left hanging - I’ve reached out to the team to get some thoughts around how to best deal with this situation. :folded_hands:

I previously recall a different scenario with a Team converting an internal Workspace to a Public Workspace which had a similar impact on the scripts coming from their package library. :cry:

I wouldn’t recommend going done the eval route, it’s the reason why we introduced reusable scripts to avoid having those hacky workarounds.

A private (I’m guessing you’d want to keep that private) npm package could be used (additional auth setup would be needed at the team level) which would be referencing in your scripts to call functions in the package. It’s not a workflow I’ve used in that way so I wouldn’t have a walkthrough of doing that to hand.

3

UPDATE:
Found out that third party packages are resticted from internet access. I guess I left using eval or copying functions definitions all over the worksapce. Postman Community Post

Thanks for your answer! A question abount npm or JSR packages: is it possible to create a package, which uses such funtions as pm.sendRequest, pm.request.headers or console.error? For example, here is a part of my Postman script package:

async function sendRequest(options) {
    try {
        const res = await pm.sendRequest(options);
        if (res.code !== 200) {
            console.error(`Non-200 response: ${res.code}, ${res.text()}`);
            return null;
        }
        return res.json();
    } catch (e) {
        console.error(`Request failed: ${e.message}`);
        return null;
    }
}

Is it possible to create an npm or JRS package, which internally uses Postman client toolling by itself?

1 Like