Error code 1 on compile causes npm to exit

[krinsman]

This is a duplicate of #8186 . I would have commented on that issue, but Microsoft closed commenting on it, so now I have to file this as a separate issue.

Also, this issue technically isn't a duplicate, since the above issue was for Windows only, but this is happening on Linux.

Anyway, I am using a complicated JavaScript library with somewhat ambiguous documentation, so the community-created TypeScript interface file for it isn't always 100% perfect. So often I will have perfectly valid code (in terms of allowed types and whatnot), but TypeScript will still exit with an error code of 1 because the interface file for this library is, again, not 100% perfect.

This would be fine, except that when TypeScript is being run within an npm workflow (via npm run build), it causes the entire npm build script to fail entirely. So now I can't update my code.

Here is the output from npm

src/index.ts(77,52): error TS2345: Argument of type 'object' is not assignable to parameter of type 'string'.
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] build: `tsc`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /krinsman/.npm/_logs/2018-08-10T14_29_16_882Z-debug.log

Here's the log

0 info it worked if it ends with ok
1 verbose cli [ '/krinsman/miniconda/envs/test/bin/node',
1 verbose cli   '/krinsman/miniconda/envs/test/bin/npm',
1 verbose cli   'run',
1 verbose cli   'build' ]
2 info using [email protected]
3 info using [email protected]
4 verbose run-script [ 'prebuild', 'build', 'postbuild' ]
5 info lifecycle [email protected]~prebuild: [email protected]
6 info lifecycle [email protected]~build: [email protected]
7 verbose lifecycle [email protected]~build: unsafe-perm in lifecycle true
8 verbose lifecycle [email protected]~build: PATH: /krinsman/miniconda/envs/test/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/krinsman/package/node_modules/.bin:/krinsman/miniconda/envs/test/bin
9 verbose lifecycle [email protected]~build: CWD: /krinsman/package
10 silly lifecycle [email protected]~build: Args: [ '-c', 'tsc' ]
11 silly lifecycle [email protected]~build: Returned: code: 1  signal: null
12 info lifecycle [email protected]~build: Failed to exec build script
13 verbose stack Error: [email protected] build: `tsc`
13 verbose stack Exit status 1
13 verbose stack     at EventEmitter.<anonymous> (/krinsman/miniconda/envs/test/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:285:16)
13 verbose stack     at emitTwo (events.js:126:13)
13 verbose stack     at EventEmitter.emit (events.js:214:7)
13 verbose stack     at ChildProcess.<anonymous> (/krinsman/miniconda/envs/test/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
13 verbose stack     at emitTwo (events.js:126:13)
13 verbose stack     at ChildProcess.emit (events.js:214:7)
13 verbose stack     at maybeClose (internal/child_process.js:925:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5)
14 verbose pkgid [email protected]
15 verbose cwd /krinsman/package
16 verbose Linux 4.4.114-94.11-default
17 verbose argv "/krinsman/miniconda/envs/test/bin/node" "/krinsman/miniconda/envs/test/bin/npm" "run" "build"
18 verbose node v8.11.3
19 verbose npm  v5.6.0
20 error code ELIFECYCLE
21 error errno 1
22 error [email protected] build: `tsc`
22 error Exit status 1
23 error Failed at the [email protected] build script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]

[ghost]

Even if the interface is wrong, you should be able to avoid compile errors in your source code using as any casts. So if there's a method you want to call that doesn't exist, you could change obj.m() to (obj as any).m().

[krinsman]

@Andy-MS This helped me. Is this in the docs? If not, I can try to get around to making a PR to add them sometime (assuming the docs are PR'able -- I haven't checked as you might have guessed).

[RyanCavanaugh]

See also #13280

[ghost]

Docs: Search "type assertions" in the handbook.
By the way, the method I described isn't always the best -- you might also use declaration merging to add new methods to the interface. (Or better, you could contribute them to DefinitelyTyped.)