profile
viewpoint

ogrodnek/spark-plug 40

scala driver for launching Amazon EMR jobs

floodfx/aws-tools 17

Deprecated. Use https://aws.amazon.com/cli/ instead...

stephenh/bindgen 12

data binding framework

stephenh/apt-util 3

util classes for writing java annotation processors

jcarver989/anagram 2

Annotation tool for design reviews

stephenh/avow 2

a semi-fluent assertions library

stephenh/bd 2

a distraction i don't need--should just go back to ant

stephenh/album23 1

uploading files to 23hq.com (via their flickr-ish API)

stephenh/aws-ivy 1

fork of git://git.springsource.org/spring-build/aws-ivy.git

stephenh/bindgen-gwt 1

bindgen packaged as a gwt jar

delete branch stephenh/joist-ts

delete branch : bump

delete time in 28 minutes

push eventstephenh/joist-ts

Stephen Haberman

commit sha 03d3ab659cbf8aa4de78365987d38d207f4d3e12

Bump node/pg/pg-structure/knex. (#50)

view details

push time in 28 minutes

PR merged stephenh/joist-ts

Bump node/pg/pg-structure/knex.
+58 -82

0 comment

8 changed files

stephenh

pr closed time in 29 minutes

push eventstephenh/joist-ts

Stephen Haberman

commit sha 43258b8e2a4c005337187b4eeb354ec244421f4d

Bump node/pg/pg-structure/knex.

view details

push time in 33 minutes

PR opened stephenh/joist-ts

Bump node/pg/pg-structure/knex.
+58 -82

0 comment

8 changed files

pr created time in 35 minutes

create barnchstephenh/joist-ts

branch : bump

created branch time in 41 minutes

Pull request review commenthomebound-team/truss

Add maxWidth and maxHeight rules

-import { RuleFn } from "./RuleConfig";-import { makeIncRules, makeRules } from "../utils";+import { RuleFn } from './RuleConfig';

This should still be "?

ksk5280

comment created time in a day

Pull request review commenthomebound-team/truss

Add maxWidth and maxHeight rules

-import { RuleFn } from "./RuleConfig";-import { makeIncRules, makeRules } from "../utils";+import { RuleFn } from './RuleConfig';+import { makeIncRules, makeRules } from '../utils';  export const heightRules: RuleFn = (config) => [   // https://github.com/tachyons-css/tachyons/blob/master/src/_heights.css    // Technically h1 in tachyons is 1em and ours is 1 inc-  ...makeIncRules(config, "h", "height"),+  ...makeIncRules(config, 'h', 'height'), -  ...makeRules("height", {-    h25: "25%",-    h50: "50%",-    h75: "75%",-    h100: "100%",-    vh25: "25vh",-    vh50: "50vh",-    vh75: "75vh",-    vh100: "100vh",+  ...makeRules('height', {+    h25: '25%',+    h50: '50%',+    h75: '75%',+    h100: '100%',+    vh25: '25vh',+    vh50: '50vh',+    vh75: '75vh',+    vh100: '100vh',   }),    ...makeRules(-    "minHeight",+    'minHeight',     {       mh0: 0,-      mh100: "100%",-      mvh100: "100vh",+      mh25: '25%',+      mh50: '50%',+      mh575: '75%',

An extra 5 I think.

ksk5280

comment created time in a day

issue commentrobinweser/fela

Support selectors with two ampersands

Ah cool, thanks for that link. That "on parent hover, style a child" is a use case we'd come across / struggled with as well :-). The identifier approach looks nice, I'll keep that in mind...

stephenh

comment created time in 2 days

Pull request review commentstephenh/ts-proto

Fix DataLoader interface not being added

 export function generateFile(typeMap: TypeMap, fileDesc: FileDescriptorProto, pa     }   } +  if (options.useContext) {+    file = file.addInterface(generateDataLoadersType());+  }

Cool, that does sound nuanced :-) and sure sounds fine.

Can you remove the addInterface(generateDataLoadersType()) from the if (options.outputClientImpl && fileDesc.service.length > 0) { condition right above this, as part of your PR?

As-is, DataLoaders with your change is being added twice if both outputClientImpl and useContext are set.

So, small tweak, but then will merge + release.

djedlajn

comment created time in 3 days

Pull request review commentstephenh/ts-proto

Fix DataLoader interface not being added

 export function generateFile(typeMap: TypeMap, fileDesc: FileDescriptorProto, pa     }   } +  if (options.useContext) {+    file = file.addInterface(generateDataLoadersType());+  }

Maybe I’m missing something but if I don’t want client-related code I can’t have DataLoaders generates properly

Yeah, that is currently the case, which yeah we can pretty easily change.

Although, sanity checking my understanding here, if you have outputClientImpl=false, does anything in the ts-proto generated code even need / reference DataLoaders?

I'm ~80% sure that only the client impl code uses the DataLoaders stuff, so I'm just wondering/curious what you're using DataLoaders for? (Or am I forgetting something about ts-protos output?)

djedlajn

comment created time in 3 days

Pull request review commentstephenh/ts-proto

Fix DataLoader interface not being added

 export function generateFile(typeMap: TypeMap, fileDesc: FileDescriptorProto, pa     }   } +  if (options.useContext) {+    file = file.addInterface(generateDataLoadersType());+  }

Hey, so this is also done a few lines above this:

  if (options.outputClientImpl && fileDesc.service.length > 0) {
    file = file.addInterface(generateRpcType(options));
    if (options.useContext) {
      file = file.addInterface(generateDataLoadersType());
    }
  }

That in theory already does this.

Is there part of that outputClientImpl && fileDesc.service.length condition that is wrong for your setup? Do you have outputClientImpl=true set?

djedlajn

comment created time in 4 days

issue commentemotion-js/emotion

jest-emotion No support for CSS pseudo-elements and pseudo-classes

@Andarist I played with this a bit and figured out it does basically work, i.e. for this:

        css={{
          "&:hover": { marginBottom: "16px", ...Css.pb3.$ },
          "& > div:focus": Css.pb4.$,
          "& > div + div": Css.pt4.$,
        }}

The following assertions work:

    expect(div).toHaveStyleRule("margin-bottom", "16px", { target: ":hover" });
    expect(div).toHaveStyleRule("padding-bottom", "32px", {
      target: "div:focus",
    });
    expect(div).toHaveStyleRule("padding-top", "32px", {
      target: "div",
    });

So, :hover is straight forward--just drop the &.

For & > div:focus, drop the & and > and it's div:focus.

For & > div + div, drop the & and > and + and the combine (kinda weird) the divs into just one div so it's just div.

I cheated a little bit on the repro and made a throw-away branch in an existing project that already had emotion / jest-emotion setup:

https://github.com/homebound-team/truss/blob/emotion-style-test/integration-test/Css.emotion.test.tsx#L54

So, I think I'm technically unblocked b/c, with enough attempts, I can basically stripe characters until finding the right selector, but it's not incredibly intuitive. Would be great to tweak this somehow to perhaps leave in some more of the characters? Or maybe just all of them? Fwiw that would have been the most intuitive / what I tried first, i.e. typing the target: ... to be exactly like the selector I passed to css (i.e. including & and including whitespace).

Thanks!

Tokery

comment created time in 4 days

create barnchhomebound-team/truss

branch : emotion-style-test

created branch time in 4 days

Pull request review commentstephenh/ts-proto

Add support for generating service client implementations with JSON serialization

+import { SimpleServiceClientImpl, SimpleServiceJsonClientImpl } from './simple_service';+import { Simple, StateEnum, Child_Type } from './simple';++const simple: Simple = {+  name: 'asdf',+  age: 1,+  child: { name: 'child', type: Child_Type.UNKNOWN },+  state: StateEnum.ON,+  grandChildren: [+    { name: 'grand1', type: Child_Type.UNKNOWN },+    { name: 'grand2', type: Child_Type.UNKNOWN },+  ],+  coins: [2, 4, 6],+  snacks: ['a', 'b'],+  oldStates: [StateEnum.ON, StateEnum.OFF],+  createdAt: new Date('1970-01-01T00:00:00.000Z'),+  thing: undefined,+  blobs: [],+};++describe('simple service', () => {+  it('can echo with protobuf serialization', async () => {+    const echoRpc = {+      request: (_service: string, _method: string, data: Uint8Array) => {+        return Promise.resolve(data);+      },+      requestJson: (_service: string, _method: string, data: unknown) => {

I was initially confused by this Rpc having to have both request and requestJson ... kinda thinking we should just generate separate Rpc interfaces, i.e. the current Rpc stays as is and becomes BinaryRpc and the new one would be a JsonRpc?

isherman

comment created time in 4 days

Pull request review commentstephenh/ts-proto

Add support for generating service client implementations with JSON serialization

 function generateCachingRpcMethod(  * types.  */ function generateRpcType(options: Options): InterfaceSpec {-  const data = TypeNames.anyType('Uint8Array');-  let fn = FunctionSpec.create('request');+  let rpc = InterfaceSpec.create('Rpc');+  if (options.useContext) {+    rpc = rpc.addTypeVariable(TypeNames.typeVariable('Context'));+  }+  rpc = rpc.addFunction(generateRpcRequestFn({ ...options, outputJsonClientImpl: false }));+  if (options.outputJsonClientImpl) {+    rpc = rpc.addFunction(generateRpcRequestFn(options));

I.e. here maybe just make a new JsonRpc that is separate from the existing Rpc type...

isherman

comment created time in 4 days

Pull request review commentstephenh/ts-proto

Add support for generating service client implementations with JSON serialization

+import { SimpleServiceClientImpl, SimpleServiceJsonClientImpl } from './simple_service';+import { Simple, StateEnum, Child_Type } from './simple';++const simple: Simple = {+  name: 'asdf',+  age: 1,+  child: { name: 'child', type: Child_Type.UNKNOWN },+  state: StateEnum.ON,+  grandChildren: [+    { name: 'grand1', type: Child_Type.UNKNOWN },+    { name: 'grand2', type: Child_Type.UNKNOWN },+  ],+  coins: [2, 4, 6],+  snacks: ['a', 'b'],+  oldStates: [StateEnum.ON, StateEnum.OFF],+  createdAt: new Date('1970-01-01T00:00:00.000Z'),+  thing: undefined,+  blobs: [],+};++describe('simple service', () => {+  it('can echo with protobuf serialization', async () => {+    const echoRpc = {+      request: (_service: string, _method: string, data: Uint8Array) => {

Ah sure, that makes sense. How about using jest.fns though so we can assert the right values are passed? I.e. expect(...).toBeCalledWith?

isherman

comment created time in 4 days

Pull request review commentstephenh/ts-proto

Add support for generating service client implementations with JSON serialization

 protoc --plugin=node_modules/ts-proto/protoc-gen-ts_proto ./batching.proto -I.  - With `--ts_proto_opt=outputClientImpl=false`, the client implementations, i.e. `FooServiceClientImpl`, that implement the client-side (currently Twirp-only) RPC interfaces will not be output. +- With `--ts_proto_opt=outputJsonClientImpl=true`, an additional client implementation will be output for each service, i.e. `FooServiceJsonClientImpl`, that uses JSON serialization. Has no effect if `outputClientImpl=false`.

What do you think about doing something like outputClientImpl = false | true | twirp | json? I.e. false is off, true is a legacy value that means twirp, and json would be your new code?

I'm kinda thinking that shops will generally have a single preferred client?

I dunno, maybe not I guess?

Maybe this is better.

Maybe outputJsonClient=true/false? I might deprecate the existing outputClientImpl and rename it to outputTwirpClient...

isherman

comment created time in 4 days

MemberEvent

push eventhomebound-team/graphql-typescript-simple-resolvers

Stephen Haberman

commit sha 002182d08d0c9dff9d6a8f5c29233871ce969a81

Make nullable args be optional keys. We don't want optional keys on output types, but args are essentially input types, so optional keys are okay.

view details

push time in 5 days

push eventstephenh/joist-ts

Chris Fox

commit sha 083bb8335334710a630333366d868d8d8d8b2e18

Add support for ILIKE operator (#49)

view details

push time in 5 days

PR merged stephenh/joist-ts

Add support for ILIKE operator

You could say, ILIKE this idea a lot.

+13 -2

0 comment

2 changed files

chr1sjf0x

pr closed time in 5 days

push eventstephenh/joist-ts

Stephen Haberman

commit sha 6f421ef0cc06382632a65621440db8ce5b604abd

Always order by id as a final orderBy for determinism.

view details

push time in 6 days

push eventstephenh/joist-ts

Stephen Haberman

commit sha fa5246f4c6ea85ac06e620a345b3137fa8b81f7e

Add missing limit/offset to findGql.

view details

push time in 6 days

push eventhomebound-team/graphql-typescript-factories

Stephen Haberman

commit sha 42c48255b4a88095eb52b1f6be189e4446fd8832

Handle optional enums.

view details

push time in 6 days

push eventhomebound-team/graphql-id-linter

Matthew Abrams

commit sha 47682dcd8a6e9217a5dd5172eaad3a6108167c43

Update npm package name in readme to be correct (#3)

view details

push time in 6 days

pull request commenthomebound-team/graphql-id-linter

Update npm package name in readme to be correct

Oh shoot, thanks for the fix!

mcabrams

comment created time in 6 days

delete branch stephenh/joist-ts

delete branch : project-entity-manager

delete time in 7 days

push eventstephenh/joist-ts

Stephen Haberman

commit sha a4f17cd01deaaf9a7d15829af9a3ed6e41b81490

Generate a project-specific EntityManager. (#48)

view details

push time in 7 days

create barnchstephenh/joist-ts

branch : project-entity-manager

created branch time in 7 days

delete branch stephenh/joist-ts

delete branch : access-context-in-hooks

delete time in 7 days

push eventstephenh/joist-ts

Stephen Haberman

commit sha 8236064c7e5633220fe792bc6a314795e6647915

Access context in hooks (#47) * Allow accessing a ctx parameter in lifecycle hooks. * Change EntityManager cstr to take ctx instead of knex. Instead knex comes from ctx.knex / HasKnex. This is basically doubling-down on the context pattern, i.e. Joist apps are defacto expected to use the context pattern. I think this is fine given it's "defacto-ness" in async-heavy environments like node / Go / etc.

view details

push time in 7 days

PR merged stephenh/joist-ts

Access context in hooks

Should let us move resolver things like:

    await ctx.eventbridge.sendBillUpdateEvent(ctx, bill.idOrFail);

Into model beforeFlush / afterCommit hooks.

I'm not entirely satisfied b/c IMO these sort of afterCommits really need to leverage database-as-a-queue such that a single transaction atomically commits both the business data change + the intent to publish an event, such that if the event publishing blows up (even the publishing to eventbridge itself) we have a retry / known-dropped-event.

Granted, this blind spot is probably fine and also super/annoyingly common where applications assume "the event system will take care of retries" but gloss over "...what if the event doesn't get to the event system in the first place"?

+433 -413

0 comment

36 changed files

stephenh

pr closed time in 7 days

push eventhomebound-team/truss

Stephen Haberman

commit sha e91fc290e00c043b33616c8f3f965f5206fe6e38

Readme updates.

view details

push time in 7 days

push eventhomebound-team/truss

Stephen Haberman

commit sha 30fd7191b8adbdf8a26e83606a22a78d8364ed8b

Update tests to use Xss/Margin.

view details

Stephen Haberman

commit sha cbb8c5dafb6358c49503ee01bd469ea93b08eda9

Fix xss example in readme.

view details

push time in 7 days

push eventhomebound-team/truss

Stephen Haberman

commit sha 7e063d38920b71814a19afa180ad1dd284dd5693

Add Xss type alias for Pick<Properties, ...>.

view details

push time in 7 days

PR opened stephenh/joist-ts

Access context in hooks
+433 -413

0 comment

36 changed files

pr created time in 7 days

push eventstephenh/joist-ts

Stephen Haberman

commit sha 1018f9a0cd2afb75d1ff70ef0eccfe51a2473fa2

Change EntityManager cstr to take ctx instead of knex. Instead knex comes from ctx.knex / HasKnex. This is basically doubling-down on the context pattern, i.e. Joist apps are defacto expected to use the context pattern. I think this is fine given it's "defacto-ness" in async-heavy environments like node / Go / etc.

view details

push time in 7 days

create barnchstephenh/joist-ts

branch : access-context-in-hooks

created branch time in 7 days

Pull request review commentstephenh/joist-ts

added beforeTransaction entity manager level hook

 export function tagIfNeeded(meta: HasTagName, id: string): string {  /** Removes the tag prefixes so we can use the keys for SQL operations. */ export function deTagIds(meta: HasTagName, keys: readonly string[]): readonly string[] {-  return keys.map((k) => keyToNumber(meta, k)).map((n) => n.toString());+  return keys.map((k) => deTagId(meta, k));+}++export function deTagId(meta: HasTagName, id: string): string;

Yeah thanks, needed this in a few places

zgavin

comment created time in 8 days

delete branch stephenh/fela

delete branch : fe-types

delete time in 9 days

issue commentapollographql/apollo-server

`didEncounterErrors` is not triggered when an error occurs in `context` creation.

We also had this issue, we had a production incident with errors being created by from context blowing up, but there was zero console output from the server.

Neither the logger nor the plugin are hit if context throws:

    plugins: [errorLogging],
    logger: {
      error: (msg: any) => console.log(msg),
      warn: (msg: any) => console.log(msg),
      debug: (msg: any) => console.log(msg),
      info: (msg: any) => console.log(msg),
    },

...

const errorLogging: PluginDefinition = {
  requestDidStart() {
    return {
      didEncounterErrors(ctx) {
        const { errors, context } = ctx;
        if (errors) {
          errors.forEach((err) => {
            context.logger.error({ err });
          });
        }
      },
    };
  },
};

That said, I get that didEncounterErrors wants to use our context which doesn't exist, hence the contextCreationDidFail suggestion, which I'm +1.

The only way we were able to see a glimpse of the error, was in our user's response payloads in the chrome dev console Network tab:

{"errors":[{"message":"Context creation failed: foo","extensions":{"code":"INTERNAL_SERVER_ERROR","exception":{"stacktrace":["Error: Context creation failed: foo","    at ApolloServer.context (/home/node/app/src/server.ts:60:13)","    at ApolloServer.<anonymous> (/home/node/app/node_modules/apollo-server-express/node_modules/apollo-server-core/src/ApolloServer.ts:847:24)","    at Generator.next (<anonymous>)","    at fulfilled (/home/node/app/node_modules/apollo-server-express/node_modules/apollo-server-core/dist/ApolloServer.js:5:58)","    at processTicksAndRejections (internal/process/task_queues.js:97:5)"]}}}]}

(Using the apollo-server-express 2.16.1.)

I'm fairly ambivalent about how this is handled, but even fwiw Apollo directly doing a hard-coded console.log seems preferable stopgap to this being silently dropped (from a console/logging perspective), so just a +1 / bump.

alexstrat

comment created time in 12 days

push eventstephenh/joist-ts

Stephen Haberman

commit sha d40d53073e33a58e86c8e925f01094365b199d0c

Remove a few done todos.

view details

Stephen Haberman

commit sha 325f1f9e1487f68478b75724823ca5f5cf9ce631

Extract addForeignKeyClause.

view details

Stephen Haberman

commit sha 896869cd8e0d7de78dd1adfb6d5578d71296c83f

Extract addPrimitiveClause.

view details

Stephen Haberman

commit sha 69ccccac6b4a55fa38b17a0a6552e574c6fd0204

Explicitly handle undefined as noop.

view details

push time in 12 days

issue commentemotion-js/emotion

jest-emotion No support for CSS pseudo-elements and pseudo-classes

I know this is a closed issue, but I can't get this to work with a non-trivial selector, i.e.:

<div css={ { "&:hover > *": { color: "red" } } }> ... </div>

expect(...).toHaveStyleRule("color", "red", { target: "&:hover > *" }

Doesn't work, and I've tried various approaches of putting spaces between/not-between & / : / > / *, including/not including &, etc., and can't seem to get anything to work.

I set a debug point inside of toMatchStyleRule and it really looks like the > * is not coming back at all for the target to later pick it up.

@Werter12 apologies for the ~year later lazy ask on a closed PR, but the docs are still light on this more esoteric selectors; are there any obvious ideas I'm missing? Thanks!

Tokery

comment created time in 12 days

fork stephenh/color

:rainbow: Javascript color conversion and manipulation library

fork in 13 days

Pull request review commenthomebound-team/truss

Add float support

+import { RuleFn } from "./RuleConfig";+import { makeRules } from "../utils";++export const floatRules: RuleFn = () =>

Maybe drop in the link // https://github.com/tachyons-css/tachyons/blob/master/src/_floats.css

KoltonG

comment created time in 13 days

push eventhomebound-team/graphql-typescript-factories

Stephen Haberman

commit sha c9aba9a90462728c569d2cee12dcdfe40f381ff6

Better null support.

view details

push time in 14 days

push eventhomebound-team/graphql-typescript-response-factories

Stephen Haberman

commit sha 920c405054a4d7aeef72778c9d2e75f8867151f3

Update to use BookOptions instead of DeepPartial.

view details

push time in 14 days

push eventhomebound-team/graphql-typescript-factories

Stephen Haberman

commit sha b008711ac1e92735b7449ad325f93480c218026d

Generate explicit AuthorOptions so that deep enum details work.

view details

push time in 14 days

push eventhomebound-team/graphql-typescript-response-factories

Stephen Haberman

commit sha 4cbed84e40ef03e1e79e38a64495a92771dcaaa9

Handle queries with top-level nullable fields.

view details

push time in 15 days

push eventhomebound-team/graphql-typescript-response-factories

Stephen Haberman

commit sha 7bd96f56b9cbfe2fdb234a8cb77e315b4ecbae21

Make newResponse smart enough to use the right data factory.

view details

Stephen Haberman

commit sha 003096906539d6454d4419fcaad642f08d0f1de6

Format.

view details

push time in 15 days

create barnchhomebound-team/graphql-typescript-response-factories

branch : master

created branch time in 15 days

push eventhomebound-team/truss

Stephen Haberman

commit sha 329722074e8838dbcd305fee31c470924b85b52f

Don't capture the literal value to avoid inferring never. In expressions that set the same key (i.e. `color`) to two separate value, TypeScript would interpret the disjointedness as meaning the type was impossible to create, and switch it to never. This wasn't a big deal unles you were trying to object spread the expression into another properties, as the `...never` would become a compile error.

view details

push time in 15 days

push eventhomebound-team/truss

Kolton Gagnon

commit sha 88e94feb333c69a827af29b82ce141d7516056ca

Add fontWeight support (#15) fix #14

view details

push time in 15 days

delete branch homebound-team/truss

delete branch : fontWeight

delete time in 15 days

issue closedhomebound-team/truss

fontWeight Support

Feature note to add fontWeight support.

.normal
.b
.fw1
.fw2
.fw3
.fw4
.fw5
.fw6
.fw7
.fw8
.fw9

Inspiration:

  • http://tachyons.io/docs/typography/font-weight/

closed time in 15 days

KoltonG

push eventstephenh/joist-ts

Stephen Haberman

commit sha bfca96b462002910e935d33805ef5b844a288fd4

Add 'more boring' op/value filters for easier UI binding.

view details

push time in 15 days

push eventhomebound-team/graphql-typescript-factories

Stephen Haberman

commit sha 9f519052c9036727e7ba102a460d07bdda46548f

Fix __typename not getting filled in for detail objects.

view details

push time in 15 days

push eventstephenh/joist-ts

Stephen Haberman

commit sha 9dc7c1e230222054fab599ba23ef70c6fc5ecee5

Format enums.graphql.

view details

push time in 15 days

push eventstephenh/joist-ts

Stephen Haberman

commit sha 1056d7fee8246f5a01a9f4e3b3dbafc82df62bd5

Add missing detag step.

view details

push time in 15 days

push eventhomebound-team/truss

Stephen Haberman

commit sha cee96cd9a6e0fb78d651047ba9340d197aab0056

Fix typo.

view details

push time in 17 days

push eventhomebound-team/truss

Stephen Haberman

commit sha cc26eced44818b8535c825724976b709996156e7

Add user-select rules.

view details

push time in 17 days

push eventhomebound-team/truss

Stephen Haberman

commit sha 27d81ca7d6990e4032d0ef01280617daf937ace5

Add vh25/50/75/100 rules.

view details

push time in 18 days

push eventhomebound-team/graphql-typescript-resolver-scaffolding

Stephen Haberman

commit sha d6e27007b2acc443605bc0891997d0e983181781

Use src/ instead of @src/.

view details

push time in 19 days

push eventstephenh/joist-ts

Stephen Haberman

commit sha f0297b67c782cc3e169ca9377e9030f3d2d10473

Use src/ instead of @src/ in graphql-codegen output.

view details

push time in 19 days

push eventstephenh/joist-ts

Stephen Haberman

commit sha bd1902dd644ea33d2bf849bf1d5bb822a600abb6

Add flag to disable prettier-organize-imports.

view details

push time in 19 days

startedsimonhaenisch/prettier-plugin-organize-imports

started time in 19 days

delete branch homebound-team/graphql-typescript-resolver-scaffolding

delete branch : fix-missing-ctx

delete time in 19 days

push eventhomebound-team/graphql-typescript-resolver-scaffolding

Stephen Haberman

commit sha 3086ecb271d707a713fdb58cff55ad3b95ebfc52

Accept the isolated ctx. (#3)

view details

push time in 19 days

startedneuledge/computed-types

started time in 19 days

pull request commentstephenh/ts-proto

enable rest parameter to use decorators in nestjs

Released as 1.27.1.

ToonvanStrijp

comment created time in 20 days

push eventstephenh/ts-proto

Stephen Haberman

commit sha ed8aea1a9fbf26e644a4147fce5da8bc4d009cef

v1.27.1

view details

push time in 20 days

created tagstephenh/ts-proto

tagv1.27.1

An idiomatic protobuf generator for TypeScript

created time in 20 days

PR merged stephenh/ts-proto

enable rest parameter to use decorators in nestjs

I would like this pull request to be merged soon :) by adding the addRestParameter=true option you can use decorators while still benefiting the strong typed features ts-proto offers.

const CurrentUser = createParamDecorator(
  (data: unknown, ctx: ExecutionContext) => {
    return {id: 1, name: 'test'};
  },
);

@Controller('hero')
@HeroServiceControllerMethods()
export class HeroController implements HeroServiceController {

  findCurrentUser(request: Empty, @CurrentUser() user: User): User | Promise<User> | Observable<User> {
    return user;
  }  
}
+618 -133

3 comments

30 changed files

ToonvanStrijp

pr closed time in 20 days

push eventstephenh/ts-proto

Toon van Strijp

commit sha a741e1327980756001283d08981b32652265efa6

enable rest parameter to use decorators in nestjs (#104) * add rest parameter option to enable decorators * add readme * format prettier * scale up resource_class * scale up resource_class * enable maxWorkers jest * rename parameter name

view details

push time in 20 days

pull request commentstephenh/ts-proto

enable rest parameter to use decorators in nestjs

Oh right, I forgot releases aren't 100% automated yet. Yep, I'll merge and release.

ToonvanStrijp

comment created time in 20 days

Pull request review commentstephenh/ts-proto

enable rest parameter to use decorators in nestjs

 export function defaultOptions(): Options {     outputClientImpl: true,     returnObservable: false,     addGrpcMetadata: false,+    addRestParameter: false,

Maybe rename this to addNestjsRestParameter? Since it seems really specific to nestjs's controllers/clients.

ToonvanStrijp

comment created time in 20 days

Pull request review commentstephenh/ts-proto

enable rest parameter to use decorators in nestjs

 function generateNestjsServiceClient(      // Use metadata as last argument for interface only configuration     if (options.addGrpcMetadata) {-      requestFn = requestFn.addParameter('metadata?', 'Metadata@grpc');+      requestFn = requestFn.addParameter(options.addRestParameter ? 'metadata' : 'metadata?', 'Metadata@grpc');+    }+    if (options.addRestParameter) {+      requestFn = requestFn.addParameter('...rest', 'any');

I was thinking it'd be nice if could directly be generated as user: User here, but I get that these annotations are very specifically something that user adds one-by-one-sy to each call site as needed. So the any makes sense.

ToonvanStrijp

comment created time in 20 days

push eventstephenh/ts-proto

Attila Nagy

commit sha 24b5209445b95391ca50198bffa4b2d02578dfec

Fix generated toJSON when an enum is in a oneOf in oneOf=properties mode (#105)

view details

push time in 20 days

PR merged stephenh/ts-proto

Fix generated toJSON when an enum is in a oneOf

Hello! I found that in oneOf=properties mode the generated toJSON does not compile if the enum is in a oneOf. In oneOf=unions mode the code compiles but if the value is not present, it serializes as "false". This PR fixes both cases.

+220 -15

1 comment

10 changed files

gyanta

pr closed time in 20 days

pull request commentstephenh/ts-proto

Fix generated toJSON when an enum is in a oneOf

Looks great, thanks for the PR!

gyanta

comment created time in 20 days

push eventhomebound-team/truss

Stephen Haberman

commit sha e5f097efee1a4c3b095851650e45ab6330b4dec2

Add newCss to make instantiation easier.

view details

push time in 21 days

push eventhomebound-team/truss

Stephen Haberman

commit sha 03b27d0b1ccf07ad96e70391b11eaf1d9d9d7689

Add Css.addIn as a primitive for adding rules in selectors.

view details

push time in 21 days

push eventstephenh/joist-ts

Stephen Haberman

commit sha ea68bf8e2e0b860d59a30840e1eeccb3e3189b98

Add idOrFail to Entity interface.

view details

push time in 21 days

push eventstephenh/joist-ts

Stephen Haberman

commit sha 6d44f18b654d427a59459e72e29e5ea58d3ae9b0

Sort the array values too, just for the history file.

view details

push time in 22 days

push eventstephenh/joist-ts

Stephen Haberman

commit sha 82e2cc5d1f2d193880403a4e44ccb32999d21e80

Use sortKeys on the history file.

view details

push time in 22 days

push eventstephenh/joist-ts

Stephen Haberman

commit sha e1dcdf981e05e47a84ca1020a5e5e582e5549ce7

Use sortKeys on the history file.

view details

push time in 22 days

delete branch stephenh/joist-ts

delete branch : graphql-template

delete time in 22 days

push eventstephenh/joist-ts

Stephen Haberman

commit sha 818efa347ec7742112d8bda17d72718a1d0c364d

Generate graphql schema files (#21) * Generate schema files. * Add save result types. * Use prettier, test that we keep long-form comments. * Comments. * Comments. * Fix dups in the history file, re-codegen. * Use single quote comments for test. * Fix re-adding bug.

view details

push time in 22 days

PR merged stephenh/joist-ts

Reviewers
Generate graphql schema files

We guess at what type Entity { ... } and type SaveEntityInput { ... } should look like and then use a .history.json file to remember what we've auto-added to allow the programmer to add/change/remove customizations on top of our initial guess.

+846 -14

0 comment

24 changed files

stephenh

pr closed time in 22 days

push eventstephenh/joist-ts

Stephen Haberman

commit sha fe9fdbf15ef86469bf1c0cc0cb69faf3b5403346

Fix re-adding bug.

view details

push time in 22 days

Pull request review commenthomebound-team/truss

Add borderStyle support

+import { RuleFn } from "./RuleConfig";+import { makeRules } from "../utils";++// http://tachyons.io/docs/themes/borders/+export const borderStyleRules: RuleFn = () =>+  makeRules("borderStyle", {+    b__dashed: "dashed",+    b__dotted: "dotted",

I think ba == "border all". Kinda ambivalent/would probably leave as is.

Add bwIncrement seems fine, although I wonder if that should be bw<Pixel> because are people really going to want like 8x, 16px, 24px borders? :-)

Another option is that we could lean on TypeScript and make these more method-ish, i.e.:

Css.ba({ width: 3 }) would mean "border all but use a border-width of 3px".

It'd take a little more work on the Truss side to define that rule because it's not a strait "value -> value" mapping like most of them are...

KoltonG

comment created time in 22 days

Pull request review commenthomebound-team/truss

Add borderStyle support

+import { RuleFn } from "./RuleConfig";+import { makeRules } from "../utils";++// http://tachyons.io/docs/themes/borders/+export const borderStyleRules: RuleFn = () =>+  makeRules("borderStyle", {+    b__dashed: "dashed",+    b__dotted: "dotted",

Hrm, it looks like bn both both borderStyle + borderWidth 0...i.e. it's "border none", so it's probably fine to also add this has "very specifically just change order style".

KoltonG

comment created time in 22 days

Pull request review commenthomebound-team/truss

Add borderStyle support

+import { RuleFn } from "./RuleConfig";+import { makeRules } from "../utils";++// http://tachyons.io/docs/themes/borders/+export const borderStyleRules: RuleFn = () =>+  makeRules("borderStyle", {+    b__dashed: "dashed",+    b__dotted: "dotted",

Add solid and none?

KoltonG

comment created time in 22 days

more