Hey guys, updated to version

0.57.2

today and it doesn’t seem like

sst start

is running the type checking or linting anymore. Didn’t see any changes in the release log. My

"lint"

and

"typeCheck"

values are still set to

true

in

sst.json

and

.eslintrc

is below. Any ideas?

{
  "env": {
    "es2021": true
  },
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended",
    "serverless-stack"
  ],
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaVersion": 12,
    "sourceType": "module"
  },
  "plugins": [
    "@typescript-eslint"
  ],
  "rules": {
    "@typescript-eslint/no-empty-interface": "OFF"
  }
}

We only typecheck and lint for "active" functions now

Ahh okay so, if I have an ApolloApi (one big func) that is being invoked… and I add something that should not compile in typescript, should I expect to see an error?

Hm let me check when I get home. New system should spawn linting and typechecking after

Any new deets here? I kept trying to get some type checking logs to show but couldn’t seem to do it

Hey @colin, just wanted to follow up real quick, r u still seeing the same behavior?

Hey Frank! Still seeing this behavior.. Unless I’m missing something. For example I added a block that should throw a lint error based on my config.

const foo = () => {}

But when I invoke the function, all I see is the following.

[0] Functions: Building . src/graphql/server.handler...
[0] Functions: Done building . src/graphql/server.handler (157ms)

Hey going to try to recreate this today

Cool let me know if I can assist

Hey colin how important is it to get this in the sst terminal? Do you not have this already in your editor?

@thdxr I suppose not too important, I was just expecting build failure if for example I have something that will not compile in typescript.

what we've been seeing across the ecosystem is that tools like ours don't directly do typechecking and instead rely on editor behavior. It's a bit hard to support everyone's various configurations. And for releases people generally run

tsc

prior to calling

sst deploy

Okay so maybe that is whats throwing me, I figured that tsc would throw an error

hm I don't think you need to manually run tsc for actually compilation

That was on a seed build. From the following command

npx sst build --stage dev --verbose

Just to chime in guys, @colin which build image r u using on Seed? I wonder if it’s of a different Node version as ur local.

Yep, I just upgraded the build image on Seed and that resolved the compilation issue. Sorry to distract with that @thdxr. So I think my only real question is, If I add something that should not compile in an “active” lambda, should I expect to see a tsc error when sst tries to build it? (Currently I just see the built successfully) message. Totally understand y’alls point on linting and I can tackle that any number of different ways.

@colin yeah so sst build doesn't run typechecking, people typically conflict a

tsc --noEmit

command to run before

sst deploy

@thdxr Copy that. But the same is not true for local dev with

npm start

correct? You mentioned you guys do kick off a

tsc

in that case?

Yeah we do kick it off after a function rebuilds but we do not wait for it (it's super slow) and we might remove this at some point