Jovo3, I'm being stupid again

v3
#1

Getting back to my Jovo3 project (still trying to find time to move it to Jovo4)…

As you probably don’t remember, I was finding that “jovo3 build” and “jovo3 deploy” were failing to generate the bundle.zip file. The workaround I was given was to explicitly execute “npm run bundle”.

That’s now giving me many TS1110 (Type expected) errors in library modules when it executes “tsc --p .tsconfig-build.json”. For example,

node_modules/@types/express-serve-static-core/index.d.ts:99:68 - error TS1110: Type expected.

99 type RemoveTail<S extends string, Tail extends string> = S extends `${infer P}${Tail}` ? P : S;
                                                                      ~~~

I’ve tried deleting the .tscconfig-build.json and letting “npm run bundle” recreate it. No improvement.

The generated file is:

{
  "compilerOptions": {
    "lib": [
      "es2020"
    ],
    "allowUnreachableCode": false,
    "declaration": true,
    "esModuleInterop": true,
    "module": "commonjs",
    "noImplicitAny": true,
    "noImplicitReturns": true,
    "outDir": "./dist/",
    "preserveConstEnums": true,
    "removeComments": false,
    "sourceMap": true,
    "strict": true,
    "target": "es2020",
    "resolveJsonModule": true
  },
  "include": [
    "./src/**/*",
    "./test/**/*"
  ],
  "exclude": [
    "./dist/**/*",
    "./node_modules/**/*",
    "test/**/*"
  ]
}

Windiff says the only difference between that and my own tsconfig.json is some whitespace and the addition of “test/**/*” to the exclude section. I wouldn’t have thought that either of those would cause this error.

It looks like “bundle” is defined as the script

“gulp --gulpfile node_modules/jovo-framework/gulpfile.js build-ts --cwd ./”

I should be up to date on all modules and javascript and so on.

So what obvious mistake am I making?

#2

Additional detail: The command execution and first error. From the error message, it looks like ${infer P}${Tail} ? P : S should have been replaced by a type before reaching this point. Most of the other failures seem to likewise be related to this syntax and a substitution that didn’t occur.

I’m not sure what should have performed that preprocessing, but jumping direct to npm run bundle apparently either no longer includes it, or never included it but it wasn’t needed in past versions of jovo3.

For what it’s worth, just running tsc from the command line does not produce errors.

C:\users\keshlam\jovo\new-sounds-on-demand> npm run bundle

> [email protected] bundle
> gulp --gulpfile node_modules/jovo-framework/gulpfile.js build-ts --cwd ./

[20:12:10] Using gulpfile ~\jovo\new-sounds-on-demand\node_modules\jovo-framework\gulpfile.js
[20:12:10] Starting 'build-ts'...
[20:12:10] Starting 'createTempTsConfig'...
[20:12:10] Finished 'createTempTsConfig' after 8.14 ms
[20:12:10] Starting 'compileTs'...

> [email protected] tsc
> tsc --p .tsconfig-build.json

node_modules/@types/express-serve-static-core/index.d.ts:99:68 - error TS1110: Type expected.

99 type RemoveTail<S extends string, Tail extends string> = S extends `${infer P}${Tail}` ? P : S;

Note that the failure occurs relatively early in the build-ts sequence, while executing npm run tsc – --p .tsconfig-build.json. I presume the - are doubled to get them through npm’s CLI.

If I execute that command (with the doubled -) from the command line, I get the compilation errors. If I execute tsc -p .tsconfig-build.json directly, I don’t. So this appears to be something to do with your invoking tsc through npm. And indeed:

C:\Users\keshlam\jovo\new-sounds-on-demand>tsc -version
Version 4.8.3

C:\Users\keshlam\jovo\new-sounds-on-demand>npm run tsc -- -version

> [email protected] tsc
> tsc -version

Version 3.9.10

So the question appears to be where npm is finding the obsolete version of tsc… And it appears to be

C:\Users\keshlam\jovo\new-sounds-on-demand>node_modules\.bin\tsc.cmd -version
Version 3.9.10

SOLUTION: Running npm install typescript@latest brings me to 4.8.4, which executes the npm run tsc (and the whole gulpfile) without errors (other than complaining about deprecated calls). So this was a user error, but not one this Typescript/Javascript newbie expected; I’m used to update on Linux package managers updating everything that has a newer release available without having to explicitly be told what versions to move to.

As a reminder: The reason I’m jumping through this hoop was that jovo3 build --stage lambda & jovo3 deploy did not seem to be creating the bundle.zip file. I was doing manual build and upload to work around that, and in part because I actually have two lambdas running from the same zipfile using different entry points. (There are better ways to share code between lambdas, but this was working at one point.) I’ve looked at the gulpfile code, and as far as I can tell with a few console.log() calls that zip stage wasn’t being invoked on my system.

I can try again with the updated typescript…

#3

(Apologies for the full travelogue; as I’ve warned you, I have an overcompensated writer’s block.)

#4

Thank you Joe for sharing your solution! I was running into this same issue and tried just about everything aside from updating typescript. Sure enough, updating to 4.8.4 resolved this for me as well.

#5

Glad to help. We’ve got NPM to help keep track of which versions of things depend on which other versions and keep them in synch… but someone apparently didn’t have the version of the compiler and library as explicit dependencies.

I wonder if that’s actually something a project file could specify and package authors just don’t always think to do so, or if it’s something Node doesn’t support that it should.