fregante

TL;DR: they’re not the same thing. Only sometimes they match (e.g. `id`) but often they don’t.

Something fun: JSX does not use attributes, even if they look like it. That’s why they have unusual naming/formatting (`htmlFor` and `className`)

I never intended it to be a side project, I just liked the extension and started contributing heavily to it, to the point where I became the maintainer for the next several years.

I get about that amount per month in GitHub Sponsorships. Not nearly worth the amount of time I put into it, but it’s relatively effortless work. It makes my regular work on other GitHub projects more enjoyable (due to the features that Refined GitHub adds)

Can you expand on that? Once I have such code, what’s stopping me from “stealing” the account?

- re-verify yourself with the provider, with a real ID

- get a new ID with another provider, which still points to the same fiscal code

As a global solution, it would be great to have a “real identity provider” that offers this but also allows me to log into services without giving them too much information.

Apple ID seems relatively good for this given that it lets me hide the address and change my name during registration.

I've seen links marked with `role=button` for no reason and generally roles added when one is implied (role=link is implied on anchors for example).

If aria attributes are treated as "private/testing API", then one wouldn't be surprised when the value only makes sense to bots and not humans.

In general, yeah, give me a piece of paper, there are far more people who can print some text than developers who can make a decent menu page — and it's quite sad, given it should just be a single, flat HTML page with an "index"

If you can't train on data before asking for permission, the data set becomes sparse. Thje only people who will be able to afford this will be, you guessed it, established giants who can build their own sets.

https://github.com/fregante/npm-helpful-typosquatting

Here’s what it looks like: https://www.npmjs.com/package/webext

There are people willing and able to pay, leaving those money on the table is pure waste.

That's unrelated to donations. One can accept donations without putting their soul on sale.

As an extension developer I get offers for buying my extensions or adding donator-specific functionality: I just don't accept them, even though I accept simple donations/sponsorships. The extension is still free of ads (except in the readme)

Is it worth learning it? I'm sure type-less job offers will continue to exists in large numbers, so if you don't like it then don't study it.

Note: TS is generally not referred to as "testing", this is just my simplification. I've been using TS for years for everything and it has avoided a lot of bugs — which is something I notice when porting projects to TS.

You first have to host these index.html and sw.js on a regular server (or use the URL in the readme) and then this service will serve a folder of your choice directly from your computer.

This is if you ran your trusty Python server from the CLI, except you did it from the browser, with an unchangeable host:port

The folder will appear to be published from the server that hosts that sw.js file.

    - complete inability to run code from the console into the content script context
    - content script errors are not shown in the console, you have to open a separate Browser Console
    - overall buggy dev tools (I don't remember anymore because I stopped using them a long time ago)

> One might be tempted to use the thenable interface (don’t!):

The code that followed was fine and it had no race condition.

> Seems like it would work, but it actually only waits for the promises returned from item() and not the .then() part!

This is the wrong part. The blockness is irrelevant.

No.

    async item => {await item()} // Promise<void>
    item => item() // Promise<ReturnValue<typeof item>>

> The only case where you would need to await inside the mapper function is when you would further process some asynchronously returned value

Which is what map is for. Also, once again, that was just how the async loop can be implemented. If anything you're saying that it's "a misuse" of map and thus we need an "async for"

    >  arr.map(async item => handleItem(
    >    await item()
    >  ))

> await arr.map()

That's actually a good QoL improvement, but it doesn't address either of the points I'm talking about (only works on arrays + it requires a function)

> but it actually only waits for the promises returned from item() and not the .then() part

Wrong. The mapper function returns a Promise that resolves with the return value of handleItem. `await a.then(b).then(c)` awaits the 3 promises in row.

To achieve that race condition, you should not return nor await the return value of `then` inside the map method:

    await Promise.all(
      arr.map(item => {
        const p = item();
        p.then(handleItem); // "Race condition"
        return p;
      })
    );

  for (const item of iterable)
    async do {
      await item()
    }

  Promise.all(arr.map(async item => {
    await item()
  })

This is already possible with:

  await Promise.all(arr.map(async item => {
    await item()
  })

Is anyone working on a proposal for this?

  async for (const item of iterable)
    await item()

I want to share whole jobs across my repos, including matrixes and all. I could wrap some common workflows into one action, but then the whole complexity will be hidden in a single step.

So I resorted to creating GHA Templates and manually synching them with a CLI tool[1], which isn't great, but at least I don't have to copy-paste changes across repos and I can keep a "main version" of the workflow

1: https://github.com/fregante/ghat

They hid a few buttons in a tiny dropdown that appears on hover; They kept a completely useless clickable lock icon in the middle-ish of field so now there’s a little chance that, while trying to do any of the above, you’ll end up with a popup that you have to close instead.