profile
viewpoint

alecgibson/DefinitelyTyped 0

The repository for high quality TypeScript type definitions.

alecgibson/ejs 0

Embedded JavaScript templates -- http://ejs.co

alecgibson/electron-quick-start 0

Clone to try a simple Electron app

alecgibson/epub-gen 0

Generate EPUB books from HTML with simple API in Node.js.

issue commentshare/sharedb-redis-pubsub

Support `redis` v4

I've pushed redis-v4, which runs the test suite against each version of the driver (and fails on v4).

alecgibson

comment created time in a day

create barnchshare/sharedb-redis-pubsub

branch : redis-v4

created branch time in a day

pull request commentDefinitelyTyped/DefinitelyTyped

[sharedb] Add `receivePresence` middleware hook

Ready to merge

alecgibson

comment created time in 2 days

issue commentmicrosoft/TypeScript

Key inferred from own property cannot be used to index the property

Thanks again for the quick and informative response!

alecgibson

comment created time in 2 days

issue closedmicrosoft/TypeScript

Key inferred from own property cannot be used to index the property

Bug Report

<!-- Please fill in each section completely. Thank you! -->

๐Ÿ”Ž Search Terms

infer this property key generic

๐Ÿ•— Version & Regression Information

<!-- When did you start seeing this bug occur?

"Bugs" that have existed in TS for a long time are very likely to be FAQs; refer to https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs

If possible, please try testing the nightly version of TS to see if it's already been fixed. For npm: typescript@next This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly

Note: The TypeScript Playground can be used to try older versions of TypeScript.

Please keep and fill in the line that best applies: -->

  • This is the behavior in every version I tried, and I reviewed the FAQ for entries about "this", "property", "generic"

โฏ Playground Link

<!-- A link to a TypeScript Playground "Share" link which shows this behavior

The TypeScript Workbench can be used for more complex setups, try https://www.typescriptlang.org/dev/bug-workbench/

As a last resort, you can link to a repo, but these will be slower for us to investigate. --> Playground link with relevant code

๐Ÿ’ป Code

<!-- Please post the relevant code sample here as well-->

class Parent {
  public config = {
    foo: 'lorem',
  };

  public access<K extends keyof this['config']>(key: K): this['config'][K] {
    return this.config[key];
  }
}

class Child extends Parent {
  public override config = {
    foo: 'lorem',
    bar: 'ipsum',
  };
}

new Parent().access('foo');
// @ts-expect-error
new Parent().access('bar');

new Child().access('foo');
new Child().access('bar');
// @ts-expect-error
new Child().access('baz');

๐Ÿ™ Actual behavior

Compilation error:

Type 'K' cannot be used to index type '{ foo: string; }'.(2536)

๐Ÿ™‚ Expected behavior

I'd expect the above code to compile, since K is defined as a key of {foo: string}

(Edit: simplified example by replacing getters with dumb properties)

closed time in 2 days

alecgibson

issue commentmicrosoft/TypeScript

Key inferred from own property cannot be used to index the property

That's a shame. It might be nice to be able to clarify intent with something like as const, which would effectively tie the two types together. That would basically make it possible to "opt in" to my expected behaviour (which would opt out of the ability to do your example).

class Parent {
  public config = {
    foo: 'lorem',
  } as const; // added `as const`, to show that this shouldn't change

  public mut() {
    // @ts-expect-error
    this.config.foo = 'ergo';
  }

  public access<K extends keyof this['config']>(key: K): this['config'][K] {
    return this.config[key];
  }
}

Anyway, I realise this is niche. Just thought I'd flag it, since I found it unexpected.

alecgibson

comment created time in 2 days

issue openedmicrosoft/TypeScript

Key inferred from own property cannot be used to index the property

Bug Report

<!-- Please fill in each section completely. Thank you! -->

๐Ÿ”Ž Search Terms

infer this property key generic

๐Ÿ•— Version & Regression Information

<!-- When did you start seeing this bug occur?

"Bugs" that have existed in TS for a long time are very likely to be FAQs; refer to https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs

If possible, please try testing the nightly version of TS to see if it's already been fixed. For npm: typescript@next This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly

Note: The TypeScript Playground can be used to try older versions of TypeScript.

Please keep and fill in the line that best applies: -->

  • This is the behavior in every version I tried, and I reviewed the FAQ for entries about "this", "property", "generic"

โฏ Playground Link

<!-- A link to a TypeScript Playground "Share" link which shows this behavior

The TypeScript Workbench can be used for more complex setups, try https://www.typescriptlang.org/dev/bug-workbench/

As a last resort, you can link to a repo, but these will be slower for us to investigate. --> Playground link with relevant code

๐Ÿ’ป Code

<!-- Please post the relevant code sample here as well-->

class Parent {
  public get config() {
    return {
      foo: 'lorem',
    };
  }

  public access<K extends keyof this['config']>(key: K): this['config'][K] {
    return this.config[key];
  }
}

class Child extends Parent {
  public override get config() {
    return {
      foo: 'lorem',
      bar: 'ipsum',
    };
  }
}

new Parent().access('foo');
// @ts-expect-error
new Parent().access('bar');

new Child().access('foo');
new Child().access('bar');
// @ts-expect-error
new Child().access('baz');

๐Ÿ™ Actual behavior

Compilation error:

Type 'K' cannot be used to index type '{ foo: string; }'.(2536)

๐Ÿ™‚ Expected behavior

I'd expect the above code to compile, since K is defined as a key of {foo: string}

created time in 2 days

PullRequestReviewEvent

issue openedshare/sharedb-redis-pubsub

Support `redis` v4

The redis library release a massive breaking change in v4, which โ€” amongst other things โ€” redefines how a client is instantiated.

They have a (small) migration guide.

We should probably discuss the best way to add support for this version whilst maintaining backwards compatibility with previous versions.

created time in 7 days

Pull request review commentDefinitelyTyped/DefinitelyTyped

[sharedb] Add `receivePresence` middleware hook

 interface PresenceMessage { }  type BasicCallback = (err?: Error) => void;++type ErrorHandler = (error: Error, context: ErrorHandlerContext) => void;+interface ErrorHandlerContext {+    agent?: Agent;

Isn't that what the stack trace is for? (We should probably move this conversation into sharedb)

alecgibson

comment created time in 7 days

PullRequestReviewEvent

push eventalecgibson/DefinitelyTyped

Alec Gibson

commit sha 2b2a6e5d22c8137067830e05585140acc5df5aea

[sharedb] Add `receivePresence` middleware hook - add new `receivePresence` middleware hook from https://github.com/share/sharedb/pull/522 - add new `Backend` options from https://github.com/share/sharedb/pull/524

view details

push time in 7 days

pull request commentDefinitelyTyped/DefinitelyTyped

[sharedb] Add `receivePresence` middleware hook

@ericyhwang this is ready for review now that we've release v2.2

alecgibson

comment created time in 8 days

push eventalecgibson/DefinitelyTyped

Alec Gibson

commit sha 699f62994e80680296865043b4ababfaaa2154c6

[sharedb] Add `receivePresence` middleware hook - add new `receivePresence` middleware hook from https://github.com/share/sharedb/pull/522 - add new `Backend` options from https://github.com/share/sharedb/pull/524

view details

push time in 8 days

release share/sharedb

v2.2.0

released time in 8 days

created tagshare/sharedb

tagv2.2.0

Realtime database backend based on Operational Transformation (OT)

created time in 8 days

push eventshare/sharedb

Alec Gibson

commit sha 590de68f57a257a34bc0770e67871e59e3859690

2.2.0

view details

push time in 8 days

delete branch share/sharedb

delete branch : no-send-presence-errors

delete time in 8 days

push eventshare/sharedb

Alec Gibson

commit sha 0fa66440667dfec84e0c72c9e9384b907ce5387a

๐Ÿ”’ Prevent sending `sendPresence` middleware errors to subscribers At the moment, if an error is passed in the `sendPresence` middleware, this error is broadcast to any subscribed listeners. Consumers may wish to use the `sendPresence` middleware to filter messages being sent to particular clients (eg based on authentication or other criteria). In these cases, no information at all should be broadcast to subscribers, since this might be something of a security risk - a malicious client can tell there's activity on a channel, even if they don't know exactly what that activity is. This change deprecates the current error behaviour, and adds a new flag to opt-in to the new behaviour of emitting errors on `Backend` instead of sending them down to clients. If consumers haven't actively opted in for this behaviour, they will get a deprecation warning.

view details

Alec Gibson

commit sha d13902b14fea53ef2c0f030507ac3e6e5589e976

Merge pull request #524 from share/no-send-presence-errors ๐Ÿ”’ Prevent sending `sendPresence` middleware errors to subscribers

view details

push time in 8 days

PR merged share/sharedb

๐Ÿ”’ Prevent sending `sendPresence` middleware errors to subscribers

At the moment, if an error is passed in the sendPresence middleware, this error is broadcast to any subscribed listeners.

Consumers may wish to use the sendPresence middleware to filter messages being sent to particular clients (eg based on authentication or other criteria). In these cases, no information at all should be broadcast to subscribers, since this might be something of a security risk - a malicious client can tell there's activity on a channel, even if they don't know exactly what that activity is.

This change deprecates the current error behaviour, and adds a new flag to opt-in to the new behaviour of emitting errors on Backend instead of sending them down to clients. If consumers haven't actively opted in for this behaviour, they will get a deprecation warning.

+113 -15

1 comment

5 changed files

alecgibson

pr closed time in 8 days

PullRequestReviewEvent

Pull request review commentshare/sharedb

๐Ÿ”’ Prevent sending `sendPresence` middleware errors to subscribers

 var Backend = require('../lib/backend'); var expect = require('chai').expect; var sinon = require('sinon');+var logger = require('../lib/logger');  describe('Backend', function() {   var backend;-  var agent = {-    custom: {-      foo: 'bar'-    }-  };-  var fetchOptions = {-    snapshotOptions: {-      fizz: 'buzz'-    }-  };--  beforeEach(function() {-    backend = new Backend();

I think it should be fine; if tests don't set up a backend, then the test will throw when trying to tear it down. We can rejig the tests again in that case.

alecgibson

comment created time in 8 days

push eventshare/sharedb

Alec Gibson

commit sha 0fa66440667dfec84e0c72c9e9384b907ce5387a

๐Ÿ”’ Prevent sending `sendPresence` middleware errors to subscribers At the moment, if an error is passed in the `sendPresence` middleware, this error is broadcast to any subscribed listeners. Consumers may wish to use the `sendPresence` middleware to filter messages being sent to particular clients (eg based on authentication or other criteria). In these cases, no information at all should be broadcast to subscribers, since this might be something of a security risk - a malicious client can tell there's activity on a channel, even if they don't know exactly what that activity is. This change deprecates the current error behaviour, and adds a new flag to opt-in to the new behaviour of emitting errors on `Backend` instead of sending them down to clients. If consumers haven't actively opted in for this behaviour, they will get a deprecation warning.

view details

push time in 8 days

push eventshare/sharedb

Alec Gibson

commit sha bfe2279d3e504ba528e8565e4ef33ae3f6750b86

๐Ÿ”’ Prevent sending `sendPresence` middleware errors to subscribers At the moment, if an error is passed in the `sendPresence` middleware, this error is broadcast to any subscribed listeners. Consumers may wish to use the `sendPresence` middleware to filter messages being sent to particular clients (eg based on authentication or other criteria). In these cases, no information at all should be broadcast to subscribers, since this might be something of a security risk - a malicious client can tell there's activity on a channel, even if they don't know exactly what that activity is. This change deprecates the current error behaviour, and adds a new flag to opt-in to the new behaviour of emitting errors on `Backend` instead of sending them down to clients. If consumers haven't actively opted in for this behaviour, they will get a deprecation warning.

view details

push time in 8 days

push eventshare/sharedb

Alec Gibson

commit sha a4e65356b0b215e9ed66a5428b8faeea4d0bccc1

โœจ Add `receivePresence` middleware hook At the moment, we have a [`sendPresence`][1] middleware hook, which is triggered just before a presence update is about to be sent to a client. This existing hook is useful for determining if a client should receive an update or not on the server. However, it doesn't let us *stop* clients from broadcasting to other clients, which we may want to do for authentication reasons, for example. This change adds a new `receivePresence` middleware hook, which is triggered when the server receives a presence message from a client, before the presence has been transformed against any ops. Passing an error to this middleware hook will return an error message to the broadcasting client (as opposed to `sendPresence`, which will send an error down to any subscribed clients). [1]: https://github.com/share/sharedb/blob/07f8bd98e5cdae37e925d4c0c709a1c3cbbca5e0/lib/agent.js#L816

view details

Alec Gibson

commit sha 0a94ba3a144e11098eadc66b18096e50ac503c1c

Merge pull request #522 from share/receive-presence-middleware โœจ Add `receivePresence` middleware hook

view details

Alec Gibson

commit sha ac789ea05c6ce2235ae2d5f82af5cc5458ef98bc

๐Ÿ”’ Prevent sending `sendPresence` middleware errors to subscribers At the moment, if an error is passed in the `sendPresence` middleware, this error is broadcast to any subscribed listeners. Consumers may wish to use the `sendPresence` middleware to filter messages being sent to particular clients (eg based on authentication or other criteria). In these cases, no information at all should be broadcast to subscribers, since this might be something of a security risk - a malicious client can tell there's activity on a channel, even if they don't know exactly what that activity is. This change deprecates the current error behaviour, and adds a new flag to opt-in to the new behaviour of emitting errors on `Backend` instead of sending them down to clients. If consumers haven't actively opted in for this behaviour, they will get a deprecation warning.

view details

push time in 8 days

delete branch share/sharedb

delete branch : receive-presence-middleware

delete time in 8 days

push eventshare/sharedb

Alec Gibson

commit sha a4e65356b0b215e9ed66a5428b8faeea4d0bccc1

โœจ Add `receivePresence` middleware hook At the moment, we have a [`sendPresence`][1] middleware hook, which is triggered just before a presence update is about to be sent to a client. This existing hook is useful for determining if a client should receive an update or not on the server. However, it doesn't let us *stop* clients from broadcasting to other clients, which we may want to do for authentication reasons, for example. This change adds a new `receivePresence` middleware hook, which is triggered when the server receives a presence message from a client, before the presence has been transformed against any ops. Passing an error to this middleware hook will return an error message to the broadcasting client (as opposed to `sendPresence`, which will send an error down to any subscribed clients). [1]: https://github.com/share/sharedb/blob/07f8bd98e5cdae37e925d4c0c709a1c3cbbca5e0/lib/agent.js#L816

view details

Alec Gibson

commit sha 0a94ba3a144e11098eadc66b18096e50ac503c1c

Merge pull request #522 from share/receive-presence-middleware โœจ Add `receivePresence` middleware hook

view details

push time in 8 days

PR merged share/sharedb

โœจ Add `receivePresence` middleware hook

At the moment, we have a sendPresence middleware hook, which is triggered just before a presence update is about to be sent to a client.

This existing hook is useful for determining if a client should receive an update or not on the server.

However, it doesn't let us stop clients from broadcasting to other clients, which we may want to do for authentication reasons, for example.

This change adds a new receivePresence middleware hook, which is triggered when the server receives a presence message from a client, before the presence has been transformed against any ops.

Passing an error to this middleware hook will return an error message to the broadcasting client (as opposed to sendPresence, which will send an error down to any subscribed clients).

+83 -4

4 comments

4 changed files

alecgibson

pr closed time in 8 days

issue commentshare/sharedb

Add Promise-based versions of methods in public ShareDB API

Attaching non-serialisable objects to an Error always makes me feel a little uncomfortable, since the first thing most people do is try to just log the thing to console / send up to an alert service, etc.

If instanceof makes you nervous, we could just use a good old-fashioned property:

if (error.isShareDBError) {
  switch (error.code) {
  }
}

Thoughts on whether the flag to enable promises should be "global" or specific to each Connection?

I can't immediately think of a good case where โ€” in the same codebase โ€” you'd want different code styles/error handling on a per-connection basis. I think we can just force people all-in. If they have some (weird) reason that this doesn't work, they can stay opted-out, and raise a use case with us?

ericyhwang

comment created time in 9 days

issue commentvuejs/vue-test-utils

Using `find({ref: '...'})` to target an `Element` logs a deprecation warning

I think this may have been a regression introduced by https://github.com/vuejs/vue-test-utils/pull/1910 ?

alecgibson

comment created time in 9 days

more