npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2025 – Pkg Stats / Ryan Hefner

gonzazoid.injectscript.js

v1.0.5

Published

# injectScript.js ### injectScript: (document: Document, func: string | Function, ...params: any[]) => any;

Downloads

7

Readme

injectScript.js

injectScript: (document: Document, func: string | Function, ...params: any[]) => any;

read in russian

The script is designed to work in the content scripts of extensions of chrome/opera/firefox

If we, being in the content script, need to run some code in the user land (content scripts run in their own environment and have access only to the DOM of the open page, but not to the variables and everything happening in the js on the user's side (read more), then of course we go to SO and read articles like these:

After dirty cursing, we write our lib, in which we can transfer the required function (or its source) and parameters, get the result at the output, and if during the execution there was an error - intercept it with the ability to rummage later on the stack. We do it naturally on the promises, and it does not matter what the transferred function will return - at the output we get an resolved result. Naturally after the execution, we delete the created script tag - we are neat programmers, are we? Well, after all this, we publish the written module that all suffering people could use it for. Usage (typescript, add this to content script of your extension, you can also use it when embedding code in a frame):

npm install --save gonzazoid.injectscript.js

import {injectScript} from 'gonzazoid.injectscript.js';

const payload = function(some_param: string){
    return some_param.split('.');
}

const res = injectScript(document, payload, 'some.test.string');
console.log(res); // ['some', 'test', 'string']

or find out the value of a variable (the user space variables are not available in the script content): for example, find out the version of JQuery

declare var $: any;

import {injectScript} from 'gonzazoid.injectscript.js';

const checker = function(){
    return $.fn.jquery;
}

injectScript(document, checker)
    .then((version:string)=>{

    });

or find out the version of Jquery correctly:

declare var $: any;
declare var window: Window;

import {injectScript} from 'gonzazoid.injectscript.js';
import {checkOff} from 'gonzazoid.checkoff.js';
import {sprintf} from 'gonzazoid.sprintf.js';

const checker = function(){
    const checkOff = /%checkOffSource%/;

    return (checkOff as any)(window, {$: fn: {jquery:''}}) ? $.fn.jquery : null;
};

const src = sprintf(checker.toString(), {checkOffSource: checkOff.toString()});
const version = await injectScript(document, src);

Notice how we pass our modules to the user space - we serialize them into a string. Not with each module it will pass. See:

const a = function(){
    b();
}
const b = function(){

};

module.exports = a;

If we serialize the function imported from the module to the string, we get:

const a = function(){
    b();
}

You can not create a workable function from this string - the source of function b is lost. To avoid this, the function a must be described as follows

const a = function(){
    const b = function(){

    };

    b();
}

module.exports = a;

In this case, you can serialize it to string, put it onto the script tag and it'll properly work in user land. It's the reason why for this module I had to rewrite the function serializeError taken from the npm package serialize-error - one of the auxiliary functions was described outside the main one - when imported, it was captured (javascript closures), when serialized it was be lost.

We pass the document as the first parameter - this is done in order to be able to work with frames, not only with the current document, it also reduces the number of implicitly passed parameters that makes the function closer to its mathematical definition.

The described technique can both read and write in everything that is in user land. In general, it's possible to make binding so that all userland will be mapped to the variable in the content script. Maybe I'll even write such a module. Later.

Enjoy!!!