what the fuck is js

??? does iterating it somehow change the result????

son of a bitch i will never trust js again

the RegExp needs to be recreated because it has internal states

@twinkle it depends on the specific method and regex flags IIRC; you don't have to recreate the object every time

@twinkle can’t you just reset the lastIndex property? that’s not really internal state, since it’s exposed to the user (and .exec() is documented to read and alter that…)

but i would also question why you’re even using .exec() in the first place, considering it’s a lower-level function and normally you would use .match() and .matchAll() methods of the string instead. i literally never used regexp.exec() personally

son of a bitch i will never trust js again

this is true, never trust js, always fully read the docs of features you use as they often put funny surprises in them

@kimapr if you couldn’t tell, it was 7 am when i posted it and i was working on my personal site: i was angryposting about something that wasted an hour of my life because nodejs doesn’t document things. below is a response that i’m only making because your reply is quite infuriating and demeaning and i don’t believe you intended it to be that way.

can’t you just reset the lastIndex property?

i don’t know what that is and i don’t really care to know. the thing works now and i don’t care to touch it. this property has zero documentation in the typescript definition file.

that’s not really internal state, since it’s exposed to the user

i can’t read nodejs code, as in, that’s literally not code i can just View in the workspace. all i see is what type definitions are given to me, which, there’s basically none. the documentation for exec in said definition file is:

“Executes a search on a string using a regular expression pattern, and returns an array containing the results of that search.”

at no point does it mention whatever you’re talking about.

and no, i do not care to read mdn for this: let it be known that reading mdn docs for nodejs is like reading C++ docs for C, i cannot assume something that’s documented on mdn necessarily exists on nodejs just on the basis of “i think it should exist” because i’ve hit more parities than i can count and i’ve given up on figuring out nodejs specific behaviours from docs. and no i will not read nodejs docs because the site is borderline unusable.

also– you are assuming a lot of things about me: i for one do not care about this, this is my personal site and i don’t work on it often, i just had to get it to work and that’s all that was needed. i already do enough webdev at work to not give a shit about this.

for two, i don’t know half of these details you’re assuming i should know: i don’t know these details, i don’t work with regexes, at work i would just not even bother with string manipulation and tree parsing shit like this, this is personal project stuff that i’m only doing because my site doesn’t conform to “current web best practices”. this thoroughly belongs in the category of “there is literally no reason for me to care about why this is because it’s intended to be sloppily put together because it’s my personal website and i don’t care about making it maintainable or standard or Good Quality Code.”

but i would also question why you’re even using .exec() in the first place, considering it’s a lower-level function and normally you would use .match() and .matchAll() methods of the string instead.

how about i ask you a different question: why the fuck are you questioning my usage of the function. for the benefit of the doubt that you actually don’t understand how condescending that entire sentence is, i will tell you why: because i’m doing string manipulation that requires me to iteratively exhaust a regex while slicing the original string on every iteration. as in i’m manipulating the DOM in server-side JS code:

const rendered = await Astro.slots.render("default");

const container = await experimental_AstroContainer.create();

const element = parse(rendered);
let children = [];
children.push(...element.childNodes);
for (const child of children) {
    if (child.childNodes.length > 0) {
        children.push(...child.childNodes);
    }

    // TEXT_NODE: 3
    if (child.nodeType == 3 && !!child.textContent) {
        const parent = child.parentNode;

        if (parent != undefined && parent.attributes["data-emoji"] != "true") {
            let htmlSrc = child.textContent;
            let htmlDst = "";

            let match = emojiRegex().exec(htmlSrc);
            if (match != null) {
                do {
                    const emoji = match[0];
                    const index = match["index"];
                    const before = htmlSrc.substring(0, index);
                    const after = htmlSrc.substring(index + emoji.length);
                    const emojiHtml = (await container.renderToString(Emoji, { props: { e: emoji } })).trim();
                    htmlDst += before + emojiHtml;
                    htmlSrc = after;
                    match = emojiRegex().exec(htmlSrc);
                } while (match != null);
                htmlDst += htmlSrc;

                parent.exchangeChild(child, parse(htmlDst));
            }
        }
    }
}

and what is this for? transforming literal emojis into an inline svg icon of the emoji in some predefined emoji svg files list. why is that? none of your business i have my reasoning and i shouldn’t need to tell you them. all you need to know is that i don’t care to make this code good because im not shooting for the standard practices in the first place: i repeat, this is a personal site, let me have fun in peace, i wouldn’t even use emojis in the first place at work.

i literally never used regexp.exec() personally

i don’t care, you do you, don’t bother me about it.

always fully read the docs of features you use as they often put funny surprises in them

i fully read the docs of features i use, as in, i read the lackluster typescript docs and refuse to read the mdn docs that are probably far off from nodejs implementation. this isn’t a particularly rational rejection, rather, this is a “i’ve been bitten by nodejs parities so much that i’d rather read a stackoverflow post about it.” and that’s just how i’ve grown to do things and i do not need your inputs, muchas gracias.

and no, do not tell me “just don’t use typescript”, i don’t care.

@twinkle @kimapr
> and no, i do not care to read mdn for this: let it be known that reading mdn docs for nodejs is like reading C++ docs for C, i cannot assume something that’s documented on mdn necessarily exists on nodejs just on the basis of “i think it should exist”

Btw mdn also contains:

* Links / references to ES standards. And regular expressions are a core part of JS-the-language; they are defined in the standard (as mdn mentions), and any violation of the standard by node.js would be a huge thing. For me, for things like that, mdn is just "description of standard in layperson language*.
* Support matrix, which includes node.js too, so for new or not universally supported features one can also see whether node supports them, and if so, then from which version.

Sure, there are many non-standard things documented on mdn but missing or implemented differently on node; and many recently standardized things that haven't landed in node (in stabilized way) yet; and many standard things that don't make sense outside of browsers.
But for things like regular expressions, mdn is as good as it can be, while node.js documentation sucks ass and they never bothered and will never bother to document standard JS features (which would just be a duplication of mdn).

And if at some point it happens that node processes regular expressions differently from what mdn says, that would not just be a "parity thing", that would be a huge bug either in node.js (for not following the standard correctly) or in mdn (for not describing the standard correctly).

@twinkle @kimapr also looks like what you're doing here can be replaced with a single call to `String.prototype.replace` with function argument? Won't even need to do the first check for matches then, instead just comparing original string to resulting string to determine if there were any changes.

@IngaLovinde @kimapr ah I didn’t know replace can take a function instead, i hadn’t seen it in usage before

I didn’t know regexes were a language feature of JS, well i mean i assumed it’s just standard library stuff because I don’t work with regexes in JS often anyway. that’s good to know though

@twinkle @kimapr no such thing as separation between "language feature" and "standard library" in JS (not on this level), either it's in standard or it's a vendor extension.
And mdn page on it tells you which one is it and when was it introduced and which engines support it from which version.