profile
viewpoint
Mateusz Burzyński Andarist @statelyai Wrocław, Poland

Andarist/babel-plugin-annotate-pure-calls 71

This plugins helps with annotating top level functions calls with #__PURE__ comment.

aaronshaf/react-callbag-subject 8

Asynchronous pipelines in React using callbags

aaronshaf/callbag-gamepads 7

Callbag source for connected gamepad inputs

aaronshaf/callbag-animation-frames 5

Callbag listenable source sending DOMHighResTimeStamp at display refresh rate

aaronshaf/callbag-keyboard 3

Callbag source for the keyboard

Andarist/are-hook-inputs-equal 3

A comparator function for previous and current React hook inputs.

aaronshaf/callbag-flatten-iter 2

Callbag operator that flattens iterables

Andarist/babel-check-duplicated-nodes 1

🐠 Babel helper module for transforms authors to check the AST against duplicated nodes.

Pull request review commentdmtrKovalenko/cypress-real-events

chore(deps): Update to cypress v9

 describe("cy.realTouch", () => {       })       .realTouch({ radiusX: 5, radiusY: 7 });   });--  it("touches using provided 0 for one of the axis", { retries: 4 }, (done) => {

@dmtrKovalenko any particular reason why this test was removed? it was added as part of one of my PRs since this was not working prior to that PR

dmtrKovalenko

comment created time in 28 minutes

PullRequestReviewEvent

delete branch dmtrKovalenko/cypress-real-events

delete branch : cypress-9

delete time in 29 minutes

PullRequestReviewEvent

Pull request review commentdmtrKovalenko/cypress-real-events

feat(mouse button): Allow to specify button option for `realMouseDown` and `realMouseUp`

 describe("cy.realMouseDown and cy.realMouseUp", () => {         .realMouseDown({ position: "bottomRight" })         .realMouseUp({ position: "bottomRight" });     });++    describe("options.button", () => {+      it("should allow to press down mouse using middle button", (done) => {+        cy.get(".action-btn")+          .then(($button) => {+            $button.get(0).addEventListener("mousedown", (ev) => {

Sadly the pointerdown event is not being called correctly. I've reported this issue here: https://bugs.chromium.org/p/chromium/issues/detail?id=1276003

Andarist

comment created time in 3 hours

push eventdmtrKovalenko/cypress-real-events

dependabot[bot]

commit sha b42841c40a74bf0322c7a5ae53d98b34466c0bb2

chore(deps-dev): bump @typescript-eslint/eslint-plugin (#135)

view details

dependabot[bot]

commit sha d3771e5f5cf4bd392328038558c52424826875ee

chore(deps-dev): bump cypress from 8.0.0 to 8.1.0 (#137)

view details

dependabot[bot]

commit sha 72c852d1b0d739c48a948b52b017a11f05853386

chore(deps-dev): bump eslint from 7.31.0 to 7.32.0 (#139) Bumps [eslint](https://github.com/eslint/eslint) from 7.31.0 to 7.32.0. - [Release notes](https://github.com/eslint/eslint/releases) - [Changelog](https://github.com/eslint/eslint/blob/master/CHANGELOG.md) - [Commits](https://github.com/eslint/eslint/compare/v7.31.0...v7.32.0) --- updated-dependencies: - dependency-name: eslint dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

view details

dependabot[bot]

commit sha 4baaced28bb7ec97bb1742ffbea4eb3c9115c083

chore(deps-dev): bump @typescript-eslint/parser from 4.26.0 to 4.29.1 (#143)

view details

dependabot[bot]

commit sha 42e0996cafac080fb48149f3e993694c7af8a099

chore(deps-dev): bump @typescript-eslint/eslint-plugin (#144) Bumps [@typescript-eslint/eslint-plugin](https://github.com/typescript-eslint/typescript-eslint/tree/HEAD/packages/eslint-plugin) from 4.28.5 to 4.29.1. - [Release notes](https://github.com/typescript-eslint/typescript-eslint/releases) - [Changelog](https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/CHANGELOG.md) - [Commits](https://github.com/typescript-eslint/typescript-eslint/commits/v4.29.1/packages/eslint-plugin) --- updated-dependencies: - dependency-name: "@typescript-eslint/eslint-plugin" dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

view details

Christine Zierold

commit sha 6ec5ad653c30bef317d996214a0e3f1f39006ebb

chore(docs): Add example for realHover options 📝 (#154) [#153]

view details

dependabot[bot]

commit sha c989b713e1c15077d9cf4cff0cc4c9daddf6cf3c

chore(deps-dev): bump @typescript-eslint/eslint-plugin (#152)

view details

dependabot[bot]

commit sha b19794c9d9059c580d46cc22f8697273ccf1c66a

chore(deps-dev): bump @typescript-eslint/parser from 4.29.1 to 4.29.3 (#150)

view details

dependabot[bot]

commit sha cc8701accf856de38b1a6fbcdccfcbeb13eef8ae

chore(deps-dev): bump typedoc from 0.20.37 to 0.21.6 (#149) Bumps [typedoc](https://github.com/TypeStrong/TypeDoc) from 0.20.37 to 0.21.6. - [Release notes](https://github.com/TypeStrong/TypeDoc/releases) - [Commits](https://github.com/TypeStrong/TypeDoc/compare/v0.20.37...v0.21.6) --- updated-dependencies: - dependency-name: typedoc dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

view details

jbard1

commit sha 6da62486559a6b23268efd3c70420f566f16cc12

chore: Remove .only in press.spec.ts (#156) * Remove .only in press.spec.ts and fix tests visiting Google * Undo the agree click

view details

Dmitriy Kovalenko

commit sha 79c8f28fc41e4f314ddf78c038e85325ac249d84

chore(docs): Add FAQ about visual regression services

view details

Dmitriy Kovalenko

commit sha 189671b4b893bf9eea60117c0c195b7c2b8e01a2

chore(docs): Better formulate a readme

view details

Mateusz Burzyński

commit sha fd6ed6d95d7f52f74c50596de852c62aefdf5027

feat(dblclick): allow for double clicks to be performed with `cy.realClick({ clickCount: 2 })` (#190)

view details

dependabot[bot]

commit sha 872f3d9b537417a0036beacdaf36d2649a924e56

chore(deps-dev): bump typedoc from 0.21.6 to 0.22.10 (#193) Bumps [typedoc](https://github.com/TypeStrong/TypeDoc) from 0.21.6 to 0.22.10. - [Release notes](https://github.com/TypeStrong/TypeDoc/releases) - [Changelog](https://github.com/TypeStrong/typedoc/blob/master/CHANGELOG.md) - [Commits](https://github.com/TypeStrong/TypeDoc/compare/v0.21.6...v0.22.10) --- updated-dependencies: - dependency-name: typedoc dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

view details

Dmitriy Kovalenko

commit sha a735a597c65aa7e7cae45fcbb855e3e465ccf6b8

chore(docs): Add docs about coordinartes

view details

Dmitriy Kovalenko

commit sha a329d0921cae35dffc8b11fe65ae64221bcceebf

Merge branch 'develop' of https://github.com/dmtrKovalenko/cypress-real-events into develop

view details

Dmitriy Kovalenko

commit sha bf6535d8494596ec7a82cdf5dc84d8ad1cfc304d

feat(docs): Answer how to reset hover state, closes #162

view details

Dmitriy Kovalenko

commit sha fb33d9d754c406d13fd191333f102e253c0d220e

chore(docs): Improve formatting of FAQ secton

view details

Dmitriy Kovalenko

commit sha af9839cd26989ac9768a4cfda90849b33fbfb2b7

chore(docs): Improve readme grammar

view details

Dmitriy Kovalenko

commit sha da054dbc2ca95bb22cba6bf088e204dec1ed454c

chore(deps): Update to cypress v9 (#199) * chore(deps): Update to cypress v9 * Add unsafe types casting for cypress v9 * Fix google test * chore: Remove slowing down test

view details

push time in 3 hours

create barnchdmtrKovalenko/cypress-real-events

branch : support-button-option

created branch time in 3 hours

issue commentactions/setup-node

What is default `registry-url`?

Thank you for checking this! This would match my test because I've put registry (without a scope) in the .npmrc 👍

jasonkarns

comment created time in 6 hours

issue commentemotion-js/emotion

Ability to insert styles at a specific position in <head>

However, during CSR there's no way to control where the styles are inserted inside the <head> (other than prepend option, which doesn't help here).

Since this got merged in and shipped this statement is no longer true. I'm not sure if this option has been exposed in MUI though - you'd have to look there for an answer to that.

jdb8

comment created time in 7 hours

issue openeddmtrKovalenko/cypress-real-events

Make it possible to perform actions while pressing a particular key or pointer button

To test some interactions we might have to do multiple things at once - like for example press space and move the pointer around while holding the left button of the mouse down to perform a "pan" in a canvas-based app (like in Figma, Excalidraw and more)

Should we introduce cy.realPressDown and cy.realPressUp to allow this? With this in place it should be possible to perform this sequence in a test - although it would be nice to also get some command for moving the pointer and this is related to https://github.com/dmtrKovalenko/cypress-real-events/pull/17

created time in 7 hours

pull request commentdmtrKovalenko/cypress-real-events

feat: Add cy.realDnd command

I didn't yet have time to look into this yet - it seems that you have been testing this with native [draggable] element and maybe this doesn't work for some reason.

In our app, we are implementing drag & drop in a custom way, using pointer events, and a solution similar to yours works just OK for us: <details> <summary>Custom cy.drag command</summary>

import { fireCdpCommand } from 'cypress-real-events/fireCdpCommand';
import { getCypressElementCoordinates } from 'cypress-real-events/getCypressElementCoordinates';

type Point = { x: number; y: number };

const clamp = (v: number, min: number, max: number) =>
  Math.min(Math.max(v, min), max);

const getDirection = (start: number, end: number) => {
  switch (true) {
    case end > start:
      return 1;
    case end < start:
      return -1;
    default:
      return 0;
  }
};

export const drag = (
  subject: JQuery<HTMLElement>,
  options: { target: () => Cypress.Chainable<JQuery<HTMLElement>> },
) => {
  const { target } = options;
  const sourceCoordinates = getCypressElementCoordinates(subject, 'center');
  cy.wrap(subject).realMouseDown();

  return target()
    .then(async ($target) => {
      const targetCoordinates = getCypressElementCoordinates($target, 'center');

      const direction = {
        x: getDirection(sourceCoordinates.x, targetCoordinates.x),
        y: getDirection(sourceCoordinates.y, targetCoordinates.y),
      };

      const clampPoint = (point: Point): Point => ({
        x: clamp(point.x, sourceCoordinates.x, targetCoordinates.x),
        y: clamp(point.y, sourceCoordinates.y, targetCoordinates.y),
      });

      // just fire a single pointermove event very close to ther source point
      await fireCdpCommand('Input.dispatchMouseEvent', {
        type: 'mouseMoved',
        button: 'left',
        pointerType: 'mouse',
        ...clampPoint({
          x: sourceCoordinates.x + direction.x * 1,
          y: sourceCoordinates.y + direction.y * 1,
        }),
      });

      let nextPoint = { ...sourceCoordinates };

      while (true) {
        // this doesn't move in a straight line at the moment but the movement line shouldn't matter for most of our scenarios
        // we just progress at each axis with a 10px step until we reach the target point on a given axis
        // when target points are met on both axes then we exit the "movement" phase
        nextPoint = clampPoint({
          x: nextPoint.x + direction.x * 10,
          y: nextPoint.y + direction.y * 10,
        });

        if (
          nextPoint.x === targetCoordinates.x &&
          nextPoint.y === targetCoordinates.y
        ) {
          break;
        }

        await fireCdpCommand('Input.dispatchMouseEvent', {
          type: 'mouseMoved',
          button: 'left',
          pointerType: 'mouse',
          ...nextPoint,
        });
      }

      return $target;
    })
    .then(($target) => {
      cy.wrap($target).realMouseUp();
      return $target;
    });
};

</details>

So maybe even if this doesn't work for [draggable] it would still be OK to land this feature with a documentation note about this caveat?

I see that there is an experimental Input.dispatchDragEvent command and maybe this is supposed to be used to emulate drag on [draggable] elements?

dmtrKovalenko

comment created time in 7 hours

issue openeddmtrKovalenko/cypress-real-events

Make pointer-related commands "dual"

It would be nice if I could just do this:

cy.realClick({ x: 10, y: 10 })

instead of having to do this

cy.get('body').realClick({ x: 10, y: 10 })

created time in 8 hours

pull request commentdmtrKovalenko/cypress-real-events

feat(dblclick): allow for double clicks to be performed with `cy.realClick({ clickCount: 2 })`

No worries, I know how it is - just reminding you about this, if you don't have time right now, that's fine too - I can ping you again sometime later if this won't get merged in until then.

Andarist

comment created time in 8 hours

issue openeddmtrKovalenko/cypress-real-events

Focus the AUT before actions

I think that for the majority of use cases (if not for all of them, maybe except tabbing) it makes sense to focus the AUT - without that some commands might not work properly.

I'm implementing global keyboard commands in our app so I want to use smth like to prepare the app for the assertion:

cy.realPress(['Shift', '1']);

However, this won't work because the AUT is not focused so my keyboard listener that lives in it has no chance of receiving this input.

I've tried this:

cy.get('body').focus();
cy.realPress(['Shift', '1']);

but it doesn't work even though after this we get:

cy.window().then(win => win.document.hasFocus() === true)

I've worked around my issue with:

cy.get('body').realClick({ position: 'topLeft' });
cy.realPress(['Shift', '1']);

but it feels that it could work "out of the box". I'm not entirely sure what exact command would be best to shift focus properly to the AUT before performing an action since a real click is not good in the sense that it could invoke some other, unrelated, stuff in the AUT.

created time in 8 hours

issue commentactions/setup-node

What is default `registry-url`?

Thank you for confirming - I guess I will have to dig into this deeper then, cause it doesn't match what I've seen in the debugger. This sounds especially weird to me since the publishConfig seems to me as something "closer" to the package - and as such, I think it should take a priority. This seems especially important in monorepos - where you might want to setup a default registry through some .npmrc file (at global/user/project level) but ąlso to have some of the packages to be published to another registry.

I'm also not sure if npm has this concept - but at least in Yarn Berry you can have different fetch and publish registries, so in such a context this would make even more sense cause I assume that the registry put in the .npmrc is the "fetch" registry by default (that is being used as publish and audit registry as well if there are no special values for those). And the publishConfig.registry is definitely treated there as a publish registry and, if I understand correctly, this should take a priority there. So I would at least hope for consistent behavior between npm and Yarn Berry in this regard.

But dunno, this is becoming very confusing to me 🤷‍♂️ and I certainly don't assume that my line of thinking is correct - it's just surprising that you have observed different results than I did (although our testing methodology was different so there is a chance that I've not really looked through the whole execution path).

Just a last question - did you test this with a scoped package or a non-scoped one? Maybe this can cause some differences in behavior - IIRC I've been testing this with a scoped package.

jasonkarns

comment created time in 9 hours

issue commentactions/setup-node

What is default `registry-url`?

And where the package was published at the end? to the GPR?

jasonkarns

comment created time in 10 hours

issue commentactions/setup-node

What is default `registry-url`?

Hm, I don't see anything that interesting in this log - I mean, it says which .npmrc files it has loaded but it doesn't say much about which registry it has used for the publishing itself.

What had you put in your .npmrc through setup-node? The GPR URL? Where the package was published at the end?

jasonkarns

comment created time in 10 hours

issue commentatlassian/changesets

Write tests for publishing

given the package manager cli receive the correct params it will do the job or it's a bug on their side. They have an e2e suite that runs on many os... spawn (which I don't know about) has it's own tests too, I guess. So for me what is to test is the command we run, less the fact that npm, pnpm, yarn 1.2.3 will actually publish what what we are feeding to it. Command line is somehow a contract. Same idea when I test a server, do I need to test if my express server works or just my handler/use-case (business...) .... There's not big difference when you write the tests, but running them is much easier when you don't need to start the actual express server (time, flacky...).

I agree with the principles laid out here - although if it's not too hard to pull off I usually prefer e2e/integration tests over units. My users don't care that much how I've implemented a particular thing and how many external dependencies I've used - if they contain bugs then it's affecting my product/tool directly and it's still important for me to test if a particular dependency satisfies my requirements.

Not every e2e scenario is easy to set up and I would classify this one here as something that is definitely not easy to set up. And as I said - I'm OK with testing such things by mocking stuff etc. The problem is that those commands don't only accept the given arguments - if that would be the case then I wouldn't be much worried about the whole thing. Their execution is sensitive to cwd, env variables and the file system structure itself (.npmrc lookup etc). The docs for all of this are scattered through different pages and I think that they are not even exhaustive.

I'm not sure there's a need to ? Verdacio seems to follow the same protocol (some things maybe https://verdaccio.org/docs/cli-registry/ might have to be set either in npmrc, either though npm config). At first sight it seems realistic.

Yes, it seems that this could be enough - I've looked now through the npm docs and it also seems that we can configure both the user and global config files to be used. So we could just "mock" them with a custom Verdaccio-powered registry.

We could even potentially use proxy/https-proxy to spy on the traffic - unsure if that would really be useful with Verdaccio stuff in place, but maybe it would allow us to test the OTP stuff better (since, from what I understand, this is not supported by Verdaccio).

:) just 🚶🏼 around ... I could support this ( I haven't checked the code yet) but I use a lot changeset :) and pretty happy.

@juanpicado would you like to help us out with setting this up? This could give us a good headstart.

mitchellhamilton

comment created time in 11 hours

PullRequestReviewEvent

issue commentatlassian/changesets

audit warning for outdated ansi-regex subdependency of boxen@1 used by @changesets/cli

@dominikg would you like to prepare a PR for that?

dominikg

comment created time in a day

delete branch Andarist/next.js

delete branch : bring-back-link-deprecation-warning

delete time in a day

pull request commentAndarist/stylis-plugin-extra-scope

Add compatibility for Stylis v4

It would be nice if you could rebase that on top of @tpict changes or include him as co-author of this.

Thank you very much for this - I like that you have included additional Emotion-based tests here. I won't have time to review this right away (definitely not this week) - could you ping me about this in the next week?

drenckpohl

comment created time in a day

PullRequestReviewEvent

Pull request review commentstatelyai/xstate

[v5] Ensure that null events are not recorded

 function selectEventlessTransitions<     loop: for (const s of [stateNode].concat(       getProperAncestors(stateNode, null)     )) {-      for (const t of s.transitions) {+      if (!s.always) {+        continue;+      }+      for (const t of s.always) {         if (           t.eventType === NULL_EVENT &&

This is redundant here now

davidkpiano

comment created time in a day

PullRequestReviewEvent

Pull request review commentstatelyai/xstate

[v5] Ensure that null events are not recorded

 export class Interpreter<           } else {             this.logger(value);           }+        },+        [actionTypes.assign]: () => {+          /* No-op to prevent no implementation warning */

this should be flagged with a TODO or something as it's a strong indication that things are wired weirdly here

davidkpiano

comment created time in a day

PullRequestReviewEvent

Pull request review commentstatelyai/xstate

[v5] Ensure that null events are not recorded

 type TransitionsConfigArray<   | (TEvent extends EventObject       ? TransitionConfig<TContext, TEvent> & { event: TEvent['type'] }       : never)-  | (TransitionConfig<TContext, TEvent> & { event: '' })

Another use-case for a transition array: the planned feature of letting multiple events be handled by the same transition.

IMHO, this sounds neat at the surface and I've also wanted to introduce this in the past. But now I don't think that introducing a syntax that makes you refactor the whole chunk of code is good. A good syntax should be "appendable" and focused, should allow local modifications. If we'd process event keys we could allow stuff like:

on: { 
  "A_EVENT, B_EVENT": "go here"
}

This can even be written like this: on: { [["A_EVENT", "B_EVENT"]]: "go here" } that is allowed because JS would just stringify the array put on the computed property and stringifying an array joins elements with a comma.

A different delimited could be chosen, like whitespace, but then we couldn't leverage the computed property syntax.

I agree that this doesn't look that great and makes us "decode" the event descriptors from the property name. I'm not super attached to this idea but I think it's better not to allow this at all than to keep the array syntax in place. Having to copy-paste stuff can be a feature and not a limitation 😉 And note that the visual editor can simplify this - even if the target export syntax would involve some "duplicates" to be "emitted".

By removing this feature we don't loss expressiveness since there is a simple rewrite that can represents the same model.

💯

davidkpiano

comment created time in a day

more