zopf commented 7 years ago

I am fairly new to TypeScript, so forgive me if I'm making a newbie mistake.

I am attempting to import the postgraphql module in my index.ts file, like so:

import * as postgraphql from 'postgraphql';

TypeScript is telling me that Module ''postgraphql'' resolves to a non-module entity and cannot be imported using this construct.

For my other imports, I installed their typings using e.g. npm install --save-dev @types/underscore, but it does not appear there is a @types/postgraphql module. These typings come from https://github.com/DefinitelyTyped/DefinitelyTyped.

How do I go about setting up the proper typings for the postgraphql module so that I can use it in a TypeScript project?

ar4mirez commented 7 years ago

Did you tried just doing:

import postgraphql from 'postgraphql'

You would do import * as postgraphql from 'postgraphql'; if postgresql exports multiple keys.

Hope this helps. 🤞

zopf commented 7 years ago

I did indeed try that, but then it's an even simpler error: Cannot find module 'postgraphql'.

That is the same type of error that appears when I have not installed the typings for a module using e.g. npm install --save-dev @types/underscore.

benjie commented 7 years ago

Try

import postgraphql = require('postgraphql')

You can also add typings yourself; e.g. here's some I had to make for v4:

https://github.com/postgraphql/postgraphql/blob/1417bc37b62bae165564eaf8e844c32b312a4c4e/typings/postgraphql-build.d.ts

We're probably going to be moving from TypeScript to Flow at some point, FYI.

zopf commented 7 years ago

Still get the same Cannot find module 'postgraphql'. error with the require statement, plus another error because I have my tsconfig.module set to es2015;)

I'm making my own typings now.

Based upon this spec ( http://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html ) it seems like we should probably either have a types field in the package.json or submit a @types npm module, but the types field or default index.d.ts is preferred. I'll make a PR...

zopf commented 7 years ago

Ok hm I'm not going to make a PR just yet because, well, I don't know enough about postgraphql's build process and structure to put the definitions in the right place. My guess is that it should go in index.d.ts at the root, and the build script / npm deploy script should be updated to include it in the npm package, but please let me know where it should actually go.

Here is the type definition that I'm testing out in my project now, which seems to compile properly:

declare module 'postgraphql' {

  import { Pool, PoolConfig } from 'pg';
  import { IncomingMessage, ServerResponse } from 'http'

  export type mixed = {} | string | number | boolean | undefined | null

  export interface HttpRequestHandler {
    (req: IncomingMessage, res: ServerResponse, next?: (error?: mixed) => void): void
    (ctx: { req: IncomingMessage, res: ServerResponse }, next: () => void): Promise<void>
  }

  export type PostGraphQLOptions = {
    classicIds?: boolean,
    dynamicJson?: boolean,
    graphqlRoute?: string,
    graphiqlRoute?: string,
    graphiql?: boolean,
    pgDefaultRole?: string,
    jwtSecret?: string,
    jwtAudiences?: Array<string>,
    jwtRole?: Array<string>,
    jwtPgTypeIdentifier?: string,
    watchPg?: boolean,
    showErrorStack?: boolean,
    disableQueryLog?: boolean,
    disableDefaultMutations?: boolean,
    enableCors?: boolean,
    exportJsonSchemaPath?: string,
    exportGqlSchemaPath?: string,
    bodySizeLimit?: string,
    pgSettings?: { [key: string]: mixed },
  }

  export function postgraphql (poolOrConfig?: Pool | PoolConfig | string, schema?: string | Array<string>, options?: PostGraphQLOptions): HttpRequestHandler
  export function postgraphql (poolOrConfig?: Pool | PoolConfig | string, options?: PostGraphQLOptions): HttpRequestHandler
}

benjie commented 7 years ago

That looks about right. There's work in https://github.com/postgraphql/postgraphql/pull/383 to add typings to the compiled version but I've not had time to read up enough on it to be sure, this is the only TypeScript project I work on.

mlegenhausen commented 6 years ago

@benjie are you still planing to change to Flow? Maybe I can take again a look my ticket cause typescript has evolved a lot during my absence.

benjie commented 6 years ago

Honestly, both TypeScript and Flow cause quite significant maintenance issues - given I only work on PostGraphile a few days a month keeping either of them ticking over is a PITA. I'm considering removing them entirely. I've lost a good 5 hours of PostGraphile development time to TypeScript in the last 2 months due to library updates breaking types and thus breaking CI; and I'm currently (literally right now) having to fix a load of Flow stuff in graphile-build because I upgraded GraphQL which brings new types and suddenly I've got 269 errors to solve.

For a project you're working on full time they are both great tools, but I sink too high a percentage of my PostGraphile time into solving issues with them. Both tools in both projects are out of date because updating them is too time consuming. In addition graphile-build being plugin based does not lend itself to strong typing - particularly it's Build object is highly dynamic.

mlegenhausen commented 6 years ago

Honestly, both TypeScript and Flow cause quite significant maintenance issues

I can confirm this is annoying.

given I only work on PostGraphile a few days a month keeping either of them ticking over is a PITA.

From my experience it will only get more worse without types. Especially when you only work part time on it. How do you remember which type which variable is? Especially in such a big system. These errors are normally something good. Without them it would be try and error and you need to hope that your unit tests will catch them. This does of cause only apply when the types are also applied correctly.

I would also argue that it is easier to contribute to a good typed system that to something where you guess the whole time which variable is which type?

Maybe I can find the time and take a look in upgrade typescript, so I can better understand where the problems are.

benjie commented 6 years ago

I'm not too worried about myself forgetting the types; however there is defensiveness in that it'll protect from others breaking things in PRs, like linting and tests do 👍

Sending a PR to a typed project is good if you're adept at that tool however, many people are not - so having things in TypeScript or Flow can be a barrier to contributions over vanilla JS. So you generally have a smaller pool of possibly higher quality PRs.

The amount of time spent just keeping these tools ticking over when you just want to update an unrelated dependency in package.json is not to be underestimated. You can probably tell I'm a bit annoyed about it today, so probably not in the right frame of mind to make any concrete decisions (the temptation to just throw all my toys out the pram (remove types from everything and stick with vanilla JS) has been intense today...). If you are able to upgrade PostGraphile to the latest TypeScript that would be brilliant - you can do it directly on the postgraphile branch which isn't too large these days.

cdaringe commented 6 years ago

not that opinions are being solicited, here's an opinion from a random guy on the web 🌎 .

i've started with and injected TS into many projects over the past two years, only to gut it soon after. it's been a constant annoyance with the same emotion you've expressed above.

my latest effort however, has been much more fruitful & painless. my perception is that the community has grown, typings are updated much faster now, and there are provisions now to extend incomplete/broken interfaces so as to unblock users.

long-term TS-hater here, now siding on slightly TS positive opinion 👍

TS editor support is >> than flow too, which is something to consider!

devuxer commented 6 years ago

Before the discussion here turned to TypeScript vs. Flow, it looks as if @zopf got pretty close to making a PR for his d.ts file. This seems to have stalled because this request is still pending an answer:

My guess is that it should go in index.d.ts at the root, and the build script / npm deploy script should be updated to include it in the npm package, but please let me know where it should actually go.

I don't currently have much knowledge of how DefinitelyTyped works, but I'm curious how close @zopf's proposed d.ts file is to the current API. (Clearly, the name of the project needs to be updated from postgraphql to postgraphile, but is everything else up to date?)

And once the d.ts is brought up to date, how much effort would it take to publish it to DefinitelyTyped?

benjie commented 6 years ago

I expect the options will need updating: https://github.com/graphile/postgraphile/blob/7761bb343c129d4a7ba502f772b40ac5acf04ad1/src/postgraphile/postgraphile.ts#L17-L159

There's also a few things missing:

https://github.com/graphile/postgraphile/blob/7761bb343c129d4a7ba502f772b40ac5acf04ad1/src/index.ts#L7-L20

devuxer commented 6 years ago

@benjie, Regarding the options, given that the source file is already in TypeScript, that should be pretty straightforward.

While thinking about typings, it might make sense to update the documentation as well. The use as library page is up to date except for the absence of handleErrors.

I'm not quite sure what to do about the backwards compatibility issue. I'll have to read up on that more.

devuxer commented 6 years ago

@benjie,

Made some progress this morning on the typings:

Created an updated typings file for postgraphile based on your input above.
Since postgraphile has dependencies on postgraphile-core, created a typings file for postgraphile-core, but only attempted to create typings needed by postgraphile (my assumption was that, if postgraphile doesn't need them, other libraries won't either, but that could be wrong).
Similarly, since postgraphile-core has dependencies on graphile-build, created a typings file for graphile-build, but only attempted to create typings needed by postgraphile-core (assumption same as for postgraphile-core).

I sprinkled some todo comments throughout these files to point out types I may have captured incorrectly (e.g., there were some tricky/impossible conversions between flow and TypeScript). That said, even the things I haven't marked should be verified and tested by someone who's intimately familiar with these projects.

benjie commented 6 years ago

Great work @devuxer; what you’ve done looks good from a cursory glance, but properly validating it would require more time and most likely a TypeScript project. Maybe others following this thread can try out your definitions and let us know 👍 or 👎

devuxer commented 6 years ago

@benjie, Sounds good, and I am trying it out in a TypeScript project myself at the moment. though I'm not touching much of the surface area of the API.

sjmcdowall commented 6 years ago

@devuxer -- I am also starting a TS project using Postgraphile and would love to try this. Do you have the steps needed to properly integrate your d.ts file(s) into a TS project? Thanks!

devuxer commented 6 years ago

@sjmcdowall, All you need to do is create a folder called "typings" where your server.ts file is, and place the d.ts files in that folder.

sjmcdowall commented 6 years ago

@devuxer -- Just FYI -- I added (finally) all the typings to my project and I am getting some linting errors... [ts] Type '{ bodySizeLimit: string; graphiql: boolean; graphiqlRoute: string; graphqlRoute: string; }' is not assignable to type 'PostGraphileOptions'. Object literal may only specify known properties, and 'bodySizeLimit' does not exist in type 'PostGraphileOptions'.

I think bodySizeLimit is legit as a string ??

2 -- Argument of type 'PostGraphileOptions' is not assignable to parameter of type 'PostGraphileOptions | undefined'. Type 'import("postgraphile-core").PostGraphileOptions' is not assignable to type 'import("postgraphile").PostGraphileOptions'. Types of property 'disableDefaultMutations' are incompatible. Type 'string | undefined' is not assignable to type 'boolean | undefined'. Type 'string' is not assignable to type 'boolean | undefined'.

Am I using the wrong type here?

// Finally set our misc. options
const options: PostGraphileOptions = {
  bodySizeLimit: '5MB',
  graphiql: true,
  graphiqlRoute: '/api/graphiql',
  graphqlRoute: '/api/graphql',
};

Each of the above options are being flagged as not valid .. ??

Cheers!

(Why don't you donate / add these to the @types thing?? These are pretty good starting points and better than anything else we don't have! :)

sjmcdowall commented 6 years ago

BTW -- We found a problem in the postgraphile-core d.ts definition -- here is one that works (the other version created compile errors:

src/lib/graphql.ts:29:3 - error TS2345: Argument of type 'PostGraphileOptions' is not assignable to parameter of type 'PostGraphileOptions | undefined'.
  Type 'import("postgraphile-core").PostGraphileOptions' is not assignable to type 'import("postgraphile").PostGraphileOptions'.
    Types of property 'disableDefaultMutations' are incompatible.
      Type 'string | undefined' is not assignable to type 'boolean | undefined'.
        Type 'string' is not assignable to type 'boolean | undefined'.

OH -- and FYI -- you need to add the following to your tsconfig.js to get it to work:

"lib": ["esnext"],

This will resolve some nasty AsyncInterface errors in graphql itself ..

declare module "postgraphile-core" {
  import { Client, Pool } from "pg";
  import { Build, Context, Options, Plugin } from "graphile-build";

  export type mixed = {} | string | number | boolean | undefined | null

  type PostGraphileOptions = {
      dynamicJson?: boolean;
      classicIds?: boolean;
      disableDefaultMutations?: boolean;
      bodySizeLimit?: string;
      graphqlRoute?: string;
      graphiql?: boolean;
      graphiqlRoute?: string;
      nodeIdFieldName?: string;
      graphileBuildOptions?: Options;
      graphqlBuildOptions?: Options; // DEPRECATED!
      replaceAllPlugins?: Array<(builder: mixed) => {}>;
      appendPlugins?: Array<(builder: mixed) => {}>;
      prependPlugins?: Array<(builder: mixed) => {}>;
      skipPlugins?: Array<(builder: mixed) => {}>;
      jwtPgTypeIdentifier?: string;
      jwtSecret?: string;
      inflector?: any; // NO LONGER SUPPORTED!
      pgColumnFilter?: (mixed: any, Build: Build, Context: Context) => boolean; //
      viewUniqueKey?: string;
      enableTags?: boolean;
      readCache?: string;
      writeCache?: string;
      setWriteCacheCallback?: (fn: () => Promise<void>) => void;
      legacyRelations?: "only" | "deprecated";
      setofFunctionsContainNulls?: boolean;
      legacyJsonUuid?: boolean;
  };

  type PgConfig = Client | Pool | string;

  export const createPostGraphileSchema: (
      pgConfig: PgConfig,
      schemas: string | string[],
      options?: PostGraphileOptions
  ) => Promise<any>;

  export const watchPostGraphileSchema: (
      pgConfig: PgConfig,
      schemas: string | string[],
      options: PostGraphileOptions | undefined,
      onNewSchema: any
  ) => Promise<() => Promise<void>>;
}

cdaringe commented 6 years ago

TS can autogenerate typings for us. why not flip allowJs to false and just use the autogenerated typings? i was able to build the latest successfully w/ typings (i had to update one single export), and linked it successfully. it even found that i was incorrectly using watch instead of watchPg!

# change to tsconfig.json
    "declaration": true,                   /* Generates corresponding '.d.ts' file. */
    "declarationDir": "./build",
    "allowJs": false,

more testing to come...

benjie commented 6 years ago

PR welcome 👍

sjmcdowall commented 6 years ago

BTW -- this is awesome. I also have some hacked files from the other guy who hacked some .d.ts files that work pretty well for me .. but I don't know what to do with them to contribute them (especially as they are my hacks of someone else's work...from maybe this discussion thread! LOL) ..

If you want these files just ask and I'll pop them somewhere (maybe here?) but this auto generate scheme seems much better and can be added to the commit git logic to auto-generate before a commit or pre-publish or something?

On Jul 7, 2018, at 2:49 AM, Benjie Gillam notifications@github.com wrote:

PR welcome 👍

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/graphile/postgraphile/issues/520#issuecomment-403193724, or mute the thread https://github.com/notifications/unsubscribe-auth/AB8M7WXaAbQnT0UsC75itK4fL8Pwjnkgks5uEFnsgaJpZM4OdVAA.

cdaringe commented 6 years ago

I was a little naive--there is a bit more to it, but not obscenely more. What to do about -core's typings is still unclear. I'm not sure if there's a way to ship those as part of this build effectively. I'd rather move those to -core itself personally

sjmcdowall commented 6 years ago

Moving -core to the -core thing itself makes all the sense -- and isn't that where TS will rather look anyway for it's Typings?

I have a working set of -core typings that can be used as a comparison (as well as for postgraphile itself) if anyone is interested. Again, not my original work but hacked so it actually did work for my project .. (and what I did makes sense to me.. LOL)

On Jul 7, 2018, at 12:24 PM, Christopher Dieringer notifications@github.com wrote:

I was a little naive--there is a bit more to it, but not obscenely more. What to do about -core's typings is still unclear. I'm not sure if there's a way to ship those as part of this build effectively. I'd rather move those to -core itself personally

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/graphile/postgraphile/issues/520#issuecomment-403226712, or mute the thread https://github.com/notifications/unsubscribe-auth/AB8M7RXVFR_Afr4pK8XmdIpQ8dIGPlEjks5uEOCogaJpZM4OdVAA.

cdaringe commented 6 years ago

folks, critique and/or contribute to #794 if you can

benjie commented 6 years ago

794 is now merged; we're now 100% TypeScript 🎉

For anyone looking for simple things to do to improve our typings (a great way of contributing to the project):

[ ] We should use NextHandleFunction from connect (import { NextHandleFunction } from 'connect';) in almost all places we're currently explicitly writing out (err?: Error) => void
[ ] We need to add TypeScript typings to postgraphile-core before we ship the next postgraphile; I'm considering just taking this file and adding it to postgraphile-core: https://github.com/graphile/postgraphile/blob/master/typings/postgraphile-core.d.ts
[ ] We should probably use a wider range for our typings files; however note that if we support later @types/koa than 2.0.44 then we'll need to solve the http2 issue
```
"@types/graphql": "^0.8.2",
"@types/jsonwebtoken": "<7.2.1",
"@types/koa": "2.0.44",
"@types/pg": "^7.4.10",
```
[ ] Lots of 'any' need replacing with explicit types

Please keep pull requests small and focussed; it's rare that I have 4 hours to drop on code review! (Each of these tasks should be a separate PR.)

benjie commented 6 years ago

Huge thanks to @cdaringe for undertaking this; I've been putting it off for a year because I had a suspicion how much work it would be!

sjmcdowall commented 6 years ago

Woohoo! Can't wait to try it out and remove my old typings stuff in the project!

Is this available @next or whatever to give it a spin?

On Jul 21, 2018, at 5:57 AM, Benjie Gillam notifications@github.com wrote:

Huge thanks to @cdaringe https://github.com/cdaringe for undertaking this; I've been putting it off for a year because I had a suspicion how much work it would be!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/graphile/postgraphile/issues/520#issuecomment-406784852, or mute the thread https://github.com/notifications/unsubscribe-auth/AB8M7RUVo4oWgffv0o7Ud_586fUyFiirks5uIvsHgaJpZM4OdVAA.

benjie commented 6 years ago

It will be 👍 Need to add the postgraphile-core typings first. Hoping to get an @next out before Thursday.

sjmcdowall commented 6 years ago

Here are mine I munged

declare module "postgraphile-core" {
  import { GraphQLError, ExecutionResult } from "graphql";
  import { IncomingMessage, ServerResponse, Server } from "http";
  import * as jwt from "jsonwebtoken";

  import { GraphQLErrorExtended, PluginHookFn } from "postgraphile";

  import { Client, Pool, PoolConfig } from "pg";
  import { Build, Context, Options, Plugin } from "graphile-build";

  export type mixed = {} | string | number | boolean | undefined | null

  export type PostGraphileOptions = {
    /**
     * When true, PostGraphile will watch your database schemas and re-create the
     * GraphQL API whenever your schema changes, notifying you as it does. This
     * feature requires an event trigger to be added to the database by a
     * superuser. When enabled PostGraphile will try to add this trigger, if you
     * did not connect as a superuser you will get a warning and the trigger
     * won’t be added.
     */
    watchPg?: boolean;
    /**
     * The default Postgres role to use. If no role was provided in a provided
     * JWT token, this role will be used.
     */
    pgDefaultRole?: string;
    /**
     * Setting this to `true` enables dynamic JSON which will allow you to use
     * any JSON as input and get any arbitrary JSON as output. By default JSON
     * types are just a JSON string.
     */
    dynamicJson?: boolean;
    /**
     * If none of your `RETURNS SETOF compound_type` functions mix NULLs with the
     * results then you may set this true to reduce the nullables in the GraphQL
     * schema
     */
    setofFunctionsContainNulls?: boolean;
    /**
     * Enables classic ids for Relay support. Instead of using the field name
     * `nodeId` for globally unique ids, PostGraphile will instead use the field
     * name `id` for its globally unique ids. This means that table `id` columns
     * will also get renamed to `rowId`.
     */
    classicIds?: boolean;
    /**
     * Setting this to `true` will prevent the creation of the default mutation
     * types & fields. Database mutation will only be possible through Postgres
     * functions.
     */
    disableDefaultMutations?: boolean;
    /**
     * Enables adding a `stack` field to the error response.  Can be either the
     * boolean `true` (which results in a single stack string) or the string
     * `json` (which causes the stack to become an array with elements for each
     * line of the stack).
     */
    showErrorStack?: boolean;
    /**
     * Enables ability to modify errors before sending them down to the client
     * optionally can send down custom responses
     * (@middlewareOnly)
     */
    handleErrors?: ((
        errors: Array<GraphQLError>,
        req: IncomingMessage,
        res: ServerResponse
    ) => Array<GraphQLErrorExtended>);
    /**
     * Extends the error response with additional details from the Postgres
     * error.  Can be any combination of `['hint', 'detail', 'errcode']`.
     * Default is `[]`.
     */
    extendedErrors?: Array<string>;
    /**
     * an array of [Graphile Build](/graphile-build/plugins/) plugins to load
     * after the default plugins
     */
    appendPlugins?: Array<(builder: mixed) => {}>;
    /**
     * an array of [Graphile Build](/graphile-build/plugins/) plugins to load
     * before the default plugins (you probably don't want this)
     */
    prependPlugins?: Array<(builder: mixed) => {}>;
    /**
     * the full array of [Graphile Build](/graphile-build/plugins/) plugins to
     * use for schema generation (you almost definitely don't want this!)
     */
    replaceAllPlugins?: Array<(builder: mixed) => {}>;
    /**
     * A file path string. Reads cached values from local cache file to improve
     * startup time (you may want to do this in production).
     */
    readCache?: string;
    /**
     * A file path string. Writes computed values to local cache file so startup
     * can be faster (do this during the build phase).
     */
    writeCache?: string;
    /**
     * Enables saving the detected schema, in JSON format, to the given location.
     * The directories must exist already, if the file exists it will be
     * overwritten.
     * (@middlewareOnly)
     */
    exportJsonSchemaPath?: string;
    /**
     * Enables saving the detected schema, in GraphQL schema format, to the given
     * location. The directories must exist already, if the file exists it will
     * be overwritten.
     * (@middlewareOnly)
     */
    exportGqlSchemaPath?: string;
    /**
     * The endpoint the GraphQL executer will listen on. Defaults to `/graphql`.
     * (@middlewareOnly)
     */
    graphqlRoute?: string;
    /**
     * The endpoint the GraphiQL query interface will listen on (**NOTE:**
     * GraphiQL will not be enabled unless the `graphiql` option is set to
     * `true`). Defaults to `/graphiql`.
     * (@middlewareOnly)
     */
    graphiqlRoute?: string;
    /**
     * Set this to `true` to enable the GraphiQL interface.
     * (@middlewareOnly)
     */
    graphiql?: boolean;
    /**
     * Enables some generous CORS settings for the GraphQL endpoint. There are
     * some costs associated when enabling this, if at all possible try to put
     * your API behind a reverse proxy.
     * (@middlewareOnly)
     */
    enableCors?: boolean;
    /**
     * Set the maximum size of JSON bodies that can be parsed (default 100kB).
     * The size can be given as a human-readable string, such as '200kB' or '5MB'
     * (case insensitive).
     * (@middlewareOnly)
     */
    bodySizeLimit?: string;
    /**
     * [Experimental] Enable the middleware to process multiple GraphQL queries
     * in one request
     * (@middlewareOnly)
     */
    enableQueryBatching?: string;
    /**
     * The secret for your JSON web tokens. This will be used to verify tokens in
     * the `Authorization` header, and signing JWT tokens you return in
     * procedures.
     */
    jwtSecret?: string;
    /**
     * Options with which to perform JWT verification - see
     * https://github.com/auth0/node-jsonwebtoken#jwtverifytoken-secretorpublickey-options-callback
     * (@middlewareOnly)
     */
    jwtVerifyOptions?: jwt.VerifyOptions;
    /**
     * A comma separated list of strings that give a path in the jwt from which
     * to extract the postgres role. If none is provided it will use the key
     * `role` on the root of the jwt.
     * (@middlewareOnly)
     */
    jwtRole?: Array<string>;
    /**
     * The Postgres type identifier for the compound type which will be signed as
     * a JWT token if ever found as the return type of a procedure. Can be of the
     * form: `my_schema.my_type`. You may use quotes as needed:
     * `"my-special-schema".my_type`.
     */
    jwtPgTypeIdentifier?: string;
    /**
     * The audiences to use when verifing the JWT token. If not set the audience
     * will be `['postgraphile']`.
     * (@middlewareOnly)
     */
    jwtAudiences?: Array<string>;
    /**
     * Some one-to-one relations were previously detected as one-to-many - should
     * we export 'only' the old relation shapes, both new and old but mark the
     * old ones as 'deprecated', or 'omit' the old relation shapes entirely
     */
    legacyRelations?: "only" | "deprecated" | "omit";
    /**
     * ONLY use this option if you require the v3 typenames 'Json' and 'Uuid'
     * over 'JSON' and 'UUID'
     */
    legacyJsonUuid?: boolean;
    /**
     * Turns off GraphQL query logging. By default PostGraphile will log every
     * GraphQL query it processes along with some other information. Set this to
     * `true` to disable that feature.
     * (@middlewareOnly)
     */
    disableQueryLog?: boolean;
    /**
     * A plain object specifying custom config values to set in the PostgreSQL
     * transaction (accessed via `current_setting('my.custom.setting')`) or a
     * function which will return the same (or a Promise to the same) based on
     * the incoming web request (e.g. to extract session data)
     * (@middlewareOnly)
     */
    pgSettings?: { [key: string]: mixed } | ((req: IncomingMessage) => Promise<{ [key: string]: mixed }>);
    /**
     * Some graphile-build plugins may need additional information available on
     * the `context` argument to the resolver - you can use this function to
     * provide such information based on the incoming request - you can even use
     * this to change the response [experimental], e.g. setting cookies
     * (@middlewareOnly)
     */
    additionalGraphQLContextFromRequest?: (req: IncomingMessage, res: ServerResponse) => Promise<{}>;
    /**
     * [experimental] Plugin hook function, enables functionality within
     * PostGraphile to be expanded with plugins. Generate with
     * `makePluginHook(plugins)` passing a list of plugin objects.
     * (@middlewareOnly)
     */
    pluginHook?: PluginHookFn;
};

  type PgConfig = Client | Pool | string;

  export const createPostGraphileSchema: (
      pgConfig: PgConfig,
      schemas: string | string[],
      options?: PostGraphileOptions
  ) => Promise<any>;

  export const watchPostGraphileSchema: (
      pgConfig: PgConfig,
      schemas: string | string[],
      options: PostGraphileOptions | undefined,
      onNewSchema: any
  ) => Promise<() => Promise<void>>;
}

benjie commented 6 years ago

Should be able to pull PostGraphileOptions from postgraphile in the new release 🎉

sjmcdowall commented 6 years ago

YAY!!!

benjie commented 6 years ago

[semi-automated message] We try and keep the open issues to actual issues (bugs, etc); this seems like more of a discussion right now, so I'm closing it but please feel free to keep discussing it below 👍

graphile / crystal

How to import postgraphql in a TypeScript project? #520

794 is now merged; we're now 100% TypeScript 🎉