maybe for <@U01MV4U2EV9> - any idea why these impo...
# help
l
maybe for @thdxr - any idea why these imports are undefined in the out file? here's my `builder.ts`:
Copy code
import SchemaBuilder from '@pothos/core';
import {
  DateTime,
  dateTimeParseValue,
  dateTimeSerialize,
} from './types/scalars';

export const builder = new SchemaBuilder<{
  Scalars: {
    DateTime: {
      Input: Date;
      Output: DateTime;
    };
  };
}>({});

builder.scalarType('DateTime', {
  serialize: dateTimeSerialize,
  parseValue: dateTimeParseValue,
});

...
the build is erroring with
dateTimeSerialize is not defined
(see screenshot for the out file)
t
Interesting. We're likely going to have a few issues like this before we harden our static analyzer. Let me see, it should have replaced the actual scalar with dummy ones
l
i'm getting a similar issue with defining objects through classes like in the pothos guide - not sure if it's related?
seems like some of the imports aren't pulled through into the build
t
Yeah the static analyzer works by shaking away as much as possible so it can execute the js without issue. I hadn't tried it with classes yet so need to update it
Will do today, this is helpful
l
cool - thanks man!
getting the same issue with enums, in case it's useful!
undefined in the out.mjs
t
ok for scalars looks like I was only erasing
addScalaryType
and not calls to
scalarType
. Btw where are you importing that datetime scalar from?
if it's from that graphql scalars library you can define it with
builder.addScalarType('DateTime', DateTIme, {});
l
cool, i will give that a go thanks! we have some other custom scalars too though
t
yeah I'll fix this
l
one last q for now - i've got a version of our existing API (which is apollo server running in a huge 1.5mb lambda) and currently it seems like our existing API is outperforming the SST ideal stack one (~200ms vs ~500ms for an identical request) - this is confusing since it looks like the sst lambda is way smaller (50kb)?! wondering if i've set something up wrong, have you noticed anything re performance with the ideal stack setup?
t
is this for sst start or for a deployed lambda?
l
sst start
t
hm that's confusing because the default apollo lambda boots up a full express server and pipes your aws lambda event through it
also 50kb is smaller than I've seen so that's doubly confusing
btw pushing an update that adds support for your scalars, enums + classes
It'll be there in 1.2.10
l
ace, thanks so much @thdxr
t
also curious why you're going the class route instead of using interfaces
l
migrating from typegraphql where most of our stuff is defined with classes, but i'm not married to them! just wanted to get something up and running quickly
t
That's what I figured, cool