Nest-cli: Update typescript version to support optional chaining

[duongdev]

I'm submitting a...

[ ] Regression 
[ ] Bug report
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

Optional chaining isn't supported yet

Expected behavior

Update typescript to >=3.7.0 to get optional chaining supported.

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Environment

[System Information]
OS Version     : Linux 5.0
NodeJS Version : v12.14.0
NPM Version    : 6.13.4
[Nest Information]
platform-express version : 6.10.14
serve-static version     : 1.0.2
graphql version          : 6.5.3
common version           : 6.10.14
core version             : 6.10.14

[Kuzirashi]

It would be great if this library supported TS 3.7.

[david-golightly-leapyear]

This is more than a feature request, this is a regression. @nestjs/cli < 6.13 did not have a pinned typescript dependency, so it used the host project's TypeScript version. With the pinned dependency in 6.13, existing TypeScript projects using TS 3.7 features such as optional chaining no longer compile.

[kamilmysliwiec]

The latest version of CLI uses TypeScript version installed locally in your host project's by default, see here https://github.com/nestjs/nest-cli/blob/master/lib/compiler/typescript-loader.ts

Hence, installing the latest version of typescript is enough to support this feature.

[david-golightly-leapyear]

This doesn't seem to work with yarn modules (at least):

$ bin/yarn.sh why typescript
yarn why v1.19.1
[1/4] 🤔  Why do we have the module "typescript"...?
[2/4] 🚚  Initialising dependency graph...
[3/4] 🔍  Finding dependency...
[4/4] 🚡  Calculating file sizes...
=> Found "[email protected]"
info Has been hoisted to "typescript"
info Reasons this module exists
   - "workspace-aggregator-5b1fa587-2ed6-4024-94c5-73fb707c751c" depends on it
   - Specified in "devDependencies"
   - Hoisted from "_project_#typescript"
   - Hoisted from "_project_#leapyear-auth#typescript"
   - Hoisted from "_project_#leapyear-data-manager#typescript"
   - Hoisted from "_project_#leapyear-graphql-server#typescript"
   - Hoisted from "_project_#@leapyear#logger#typescript"
   - Hoisted from "_project_#@leapyear#ui-kit#typescript"
   - Hoisted from "_project_#leapyear-graphql-server#@nestjs#graphql#ts-morph#typescript"
info Disk size without dependencies: "48.89MB"
info Disk size with unique dependencies: "48.89MB"
info Disk size with transitive dependencies: "48.89MB"
info Number of shared dependencies: 0
=> Found "@nestjs/cli#[email protected]"
info This module exists because "_project_#leapyear-graphql-server#@nestjs#cli" depends on it.
info Disk size without dependencies: "44.03MB"
info Disk size with unique dependencies: "44.03MB"
info Disk size with transitive dependencies: "44.03MB"
info Number of shared dependencies: 0
✨  Done in 1.03s.

[kamilmysliwiec]

@david-golightly-leapyear can you share a very minimal repository which reproduces your issue?

[david-golightly-leapyear]

Since @nestjs/cli is installing its own copy of TypeScript, the TypeScriptBinaryLoader will always find that copy first. We even have "typescript": "^3.7.4" in this workspace, but due to Yarn hoisting, the actual install location is up one level from the workspace.

[kamilmysliwiec]

Since @nestjs/cli is installing its own copy of TypeScript, the TypeScriptBinaryLoader will always find that copy first

As you can see here: https://github.com/nestjs/nest-cli/blob/master/lib/compiler/typescript-loader.ts#L13, CLI will always find the copy located inside the local node_modules first.

Yarn hoisting may cause issues here though.

[david-golightly-leapyear]

As you can see here: https://github.com/nestjs/nest-cli/blob/master/lib/compiler/typescript-loader.ts#L13, CLI will always find the copy located inside the local node_modules first.

That is exactly the problem. This is my 3rd production Nest.js project, all of which have used Yarn workspaces. They're incredibly handy for sharing code in a GraphQL app where types are shared between client & server - which I'd imagine is a common use case for Nest.js.

[david-golightly-leapyear]

You can find a minimal repro using Yarn workspaces here:

https://github.com/davidgoli/nestjs-cli-bug-repro

[kamilmysliwiec]

Thank you @david-golightly-leapyear. I will clone it shortly

[david-golightly-leapyear]

FWIW, using nohoist (via "nohoist": ["**/typescript"] in package.json) does not appear to resolve this.

[kamilmysliwiec]

@david-golightly-leapyear can you test with 6.13.3 release?