Editor type safety: type safety requires compile

[justinwaite]

Another quick issue: you mentioned in the README that this had editor type safety that did not require a compile every time there is a change. I'm using VS Code and in order for it to have any type checking, it requires me to compile the projects first. Any thoughts on this? Are you using any special extensions?

Edit: for further information, Webstorm behaves in the same way -- a build is required before typechecking can occur.

Edit 2: I updated to Webstorm 2018.2 and it appears to do type checking without needing to recompile -- vs code is still an issue after updating.

[tommedema]

@jdeanwaite you're right, actually. I just confirmed this issue myself.

Turns out my code was recently compiled and I had mistakenly assumed that vscode correctly picked up the "runtime" type checks.

Not sure why vscode doesn't pickup the project. Perhaps we should open up an issue over at vscode.

[tommedema]

Reported at https://github.com/Microsoft/vscode/issues/57242

[justinwaite]

Thanks for looking into this! If you are a Webstorm user, 2018.2 works great with typechecking without compiling (they had some release notes specific to Typescript 3 features they implemented).

[justinwaite]

Make sure your Node.JS assistance is on and the JavaScript language version is set to ECMAScript 6 (In the preferences for Webstorm):

[tommedema]

@jdeanwaite I see. Are you sure the run-time typechecking works across references?

I just updated random to return a string:

But did not see any errors in the consuming sls-random:

it's supposed to complain that fetchNumber returns a string and not a number

( By the way, when hovering over a function, I don't see any of the useful type information that vscode gives, like the return type and the jsdoc info )

[justinwaite]

@tommedema

First off, in order to see the useful information, hold down CMD (if you're on a mac) and hover over the function to see details:

And you are right, it was only partially working. For instance, if I change a parameter, the new parameter shows up right away in the hints (type CMD + P on a mac while the cursor is inside of the parentheses to get hints). You can see in this image I added testing: number

However, return types were not correctly updating (like what you showed).

[justinwaite]

One thing you CAN do is do your work while running tsc -b -w to watch the files while you code. This shows up in a reasonable amount of time (a few seconds):

I actually added serverless-offline to the package and the serverless.yml script to make testing locally easier. I paired this with tsc -b -w using concurrently:

package.json:

  ...
  "scripts": {
    ...
    "watch": "rm -fr dist && tsc -b -w .",
    "offline": "concurrently --names \"WATCH, OFFLINE\" -c \"green,cyan\" \"yarn watch\" \"serverless offline start\""
    ...
  },
  ...
  "devDependencies": {
    ...
    "concurrently": "4.0.0",
    ...
  }
  ...

serverless.yml

plugins:
  - serverless-plugin-scripts
  - serverless-offline

[tommedema]

@jdeanwaite I tried tsc -b -w but it was getting stuck as soon as there was a compilation error somewhere. Editors on the other hand will do a best-effort and continue parsing the "broken" file for further typing information.

When you're doing a large refactor, you know that some packages won't compile anymore; but to make them compile (i.e. fix them) you'd want to have typing information taken from other packages. tsc -b -w only partially helps here if it happens to not get stuck before the typing information you need.

Do you get my meaning?

[justinwaite]

It's true in the circumstances of refactoring it is not very helpful -- however I haven't had any issues with it getting "stuck" when a file failed to compile. After I fix the issue it seems to move on just fine.

So definitely the best scenario would be for the editors to be able to maintain type safety without needing to compile -- not sure where to begin here. It may just be that TS3 project references are too new and editors don't know how to handle them?

EDIT: Even if that aspect does not get all the way resolved, the benefits of a monorepo and typescript still outweigh that slight disadvantage. I can live with struggling through refactors for a little bit since those are a small percentage of the time.

[tommedema]

@jdeanwaite let's wait for https://github.com/Microsoft/vscode/issues/57242 to get some attention

[justinwaite]

Yes, sounds like a plan. Also I saw you posted an inquiry on https://github.com/prisma/serverless-plugin-typescript/issues/110.. This would be better than using tsc -w.