jrieken/gulp-tsb

gulp plugin for incremental TypeScript building

gulp-tsb's Issues

Update for TypeScript 2.4.1 Module Resolution Changes

TypeScript 2.4.1 breaks building vscode using tsb: microsoft/TypeScript#16772

I believe we need to port the ts-loader fix from https://github.com/TypeStrong/ts-loader/pull/566/files

how do i specify the location of the typescript compiler

This might not be a bug, but I couldn't find any option to use the bundled (npm) version of the typescript compiler. it looks like it is using the typescript compiler from the path.

Confusion between libraries and local files

gulp-tsb matched my require to the wrong file. I had an import:

import Localizer = require('localizer');

gulp-tsb matched this to a file in the same directory, Localizer.ts, instead of to the localizer library which is in the node_modules folder.

I debugged it and identified this logic as being problematic.

Is there a reason that logic was written instead of calling ts.resolveModuleName? Maybe ts.resolveModuleName didn't exist when gulp-tsb was written (microsoft/TypeScript#1793)?

Support for TS@next in master

Does master (or other branches) already support the typescript@next branch of TS? I'm testing it and I'd like to compile with new TS@next options like lib with gulp-tsb.

Subtle errors in options passed to tsb.create() are ignored (not reported)

For example:

const cjs = tsb.create({
  outDir: 'lib',
  module: 'commonjs',
  target: 'es5',
  declaration: true,
  lib: ['es5', 'es2015', 'dom'],
  sourcemap: true,
  experimentalDecorators: true
});

gulp-tsb reports no error, even though the sourceMap option has a capitalization error.

Error out on TypeScript error

I would like my gulp task to fail if there were TypeScript compilation errors. I couldn't find a way to do this. If it's not already supported, could you consider adding an option for it?

Don't force declarations=true

I've notice that gulp-tsb forces declarations compiler options to be true. (https://github.com/jrieken/gulp-tsb/blob/master/src/builder.ts#L68-L69)
Unfortunately, this causes a lot of errors in my app, like:

Parameter 'xxx' of public method from exported class has or is using private name 'xxx'.
Type parameter 'xxx' of exported function has or is using private name 'xxx'.

Since I don't need declarations in my project, I'm fine with them.
But fixing them all in order to migrate to gulp-tsb would be a drag.
Unless it's necessary for some internal workings, please consider not setting declarations to true.

Consider using http://npmjs.org/package/prex for async coordination

I noticed that builder.ts has a fair bit of async coordination, such as the workOnNext function and the toBeEmitted, toBeCheckedSyntactically, and toBeCheckedSemantically arrays.

I wrote prex originally as part of an internal test framework, and used it in the F12 developer tools. I published the package recently as an opportunity to discuss several of the primitives with TC39 (such as CancellationToken). The package adds a number of coordination primitives to simplify various existing patterns around asynchronous coordination, and the work is based primarily off of the thread/task coordination primitives found in .NET.

A few examples of some of the available primitives that could be beneficial include:

• CancellationToken
• CountdownEvent
• Barrier

All of the primitives are built on top of, or to work with, ES6 native promises. They are especially useful when combined with async/await (available for --target ES6 currently, and for other script targets in the next TypeScript release).

gul-tsb fails with @types if tsconfig.json in sub directories

Install a workspace from the following zip file:
types.zip

• run npm install
• run gulp build

Observe: the compile fails

P:\mseng\VSCode\Playgrounds\bugs\types>gulp build
[14:33:15] Using gulpfile P:\mseng\VSCode\Playgrounds\bugs\types\gulpfile.js
[14:33:15] Starting 'build'...
"P:/mseng/VSCode/Playgrounds/bugs/types/src/test.ts(1,21): Cannot find module 'fs'."
[14:33:16] Finished 'build' after 491 ms

Open the workspace in VS Code and open test.ts. Observe: file has no compile errors.

Generating source maps?

First: great project! I've learned a lot just briefly reading through the sources. I plan on spending more time understanding this. Thank you very much.

One thing I've not figured out how to do yet is generate sourcemaps. I think I've tried both the gulp-sourcemap approach and the compiler option, but my target's lib directory still doesn't have any. Can you have a look at these portions of my gulpfile and tell me what I might be doing wrong.

const gulp = require('gulp');
const sourcemaps = require('gulp-sourcemaps');
const tsb = require('gulp-tsb');

const srcFiles = ['src/**/*.ts'];

const cjs = tsb.create({
  outDir: 'lib',
  module: 'commonjs',
  target: 'es5',
  declaration: true,
  lib: ['es5', 'es2015', 'dom'],
  sourcemaps: true,                         // Complier option
  experimentalDecorators: true
});

// Build tasks - TypeScript

gulp.task('build.cjs', function () {
  return gulp.src(srcFiles)
    .pipe(sourcemaps.init())
    .pipe(cjs())
    .pipe(sourcemaps.write('.'))    // gulp-sourcemaps, intent is to write map in same dir as .js file
    .pipe(gulp.dest('lib'));
});

Does not respect baseUrl compilerOption

Repo
In VS Code, try changing our src/tsconfig to use "moduleResolution": "node":

{
	"compilerOptions": {
		"module": "amd",
		"moduleResolution": "node",
		"noImplicitAny": false,
		"removeComments": false,
		"preserveConstEnums": true,
		"target": "es5",
		"sourceMap": false,
		"experimentalDecorators": true,
		"declaration": true,
		"noImplicitReturns": true,
		"noUnusedLocals": true,
		"noImplicitThis": true,
		"alwaysStrict": true,
		"baseUrl": ".",
		"outDir": "../out",
		"typeRoots": [
			"typings"
		]
	}
}

Run build script using tsb

Bug
vs/* modules not resolved. I believe this is because the "baseUrl" option is either not respected or being set incorrectly.

If you run tsc -p tsconfig.json, the modules are properly resolved.

Moving from "moduleResolution": "node" to "moduleResolution": "classic" would let us consume @types packages normally instead of maintaining our own copies of them

sourceRoot is not output in source maps

When I pass a sourceRoot value in the options, I expect to see it output in the .map files, like it does when I use tsc, but with gulp-tsb, I don't see it there which breaks the ability to have source files somewhere else from the map files.

lib.d.ts can't be found

Starting 1.8.2 I am getting an issue when running the compile task for vscode-docs.

The issue I am getting:

[13:37:53] Using gulpfile c:\src\vscode-docs\gulpfile.js
[13:37:53] Starting 'build-website'...
[13:37:53] Starting 'compile'...
c:\src\vscode-docs\node_modules\gulp-tsb\node_modules\typescript\lib\typescript.
js:1302
        return path.replace(/\\/g, "/");

After debugging this it seems to be a result of b468f60, Typescript does not expect passing an empty string to processRootFile which breaking hell loose.

Please provide tags

Hi,

the last published tag here is 2.0.6. Could you update them ?

Cheers,
Yadd

The TypeScript JSX compiler option is not supported.

It appears that createCompilerOptions in builder.js should map the client specified JSX value to the integer value typescriptServices.js requires.

None == 0,
Preserve == 1,
React == 2

source maps create paths relative to tsb location

I use tsb in the gulpfile of https://github.com/Microsoft/vscode-json-languageservice and observe that the generated source mapping files all source references that are relative to the tsb folder, not to my source folder.

I think the reason is on https://github.com/jrieken/gulp-tsb/blob/master/src/index.ts#L46 where the base path for the tsconfig file is set to __dirname.
The doc says:

basePath A root directory to resolve relative path entries in the config.

Given that paths in tsconfigs are typically relative to the location of the tsconfig file this should be set to that.
For the case where tsconfig is passed in as an object, I suggest to use the current working dir.

Consider adding .watch to the project

It could defer to the TS compiler's built-in watching algorithms, this way it can watch all files in the project (including imports and configs) - not just those found via processing the input files list/includes/excludes.

It would also be the last public method to make the project into a full and complete vinyl provider, AFAIK.

Typescript 2.0

Hi, have you tried running this with typescript 2.0 yet?

I have just tried but note I am a novice with typescript at the moment (I'm probably doing something wrong). I received the following error:

D:\Repos\periodic\node_modules\gulp-tsb\lib\builder.js:227
                        if (!isExternalModule(service.getSourceFile(fileName_1))) {
                                                      ^

TypeError: service.getSourceFile is not a function
    at workOnNext (D:\Repos\periodic\node_modules\gulp-tsb\lib\builder.js:227:55)
    at nextTickCallbackWith0Args (node.js:453:9)
    at process._tickCallback (node.js:382:13)

Lib needs to be updated to latest src build

Commit #33 fixed the problem where readFileSync returns a buffer instead of a string. This was due to not specifying the encoding option.

Although, the source file was fixed, the transpiled file in lib was not checked in.

The latest gulp-tsb npm continues to not specify the encoding option.

BTW: Why are the transpiled files in lib checked in? They should be .gitignored.

Initial build includes inputted files but not resolved files

For example, suppose I give App.ts as input to gulp-tsb:

// App.tsx

import Helper = require('./Helper');

Helper.doSomething()

On the initial build, gulp-tsb will not fully process Helper.ts. It will fully process it when you do an incremental build. This leads to the following symptom. If Helper.ts contains a type error, the initial build won't report it. You'll see it when you do an incremental build.

This is inconsistent with how the TypeScript compiler behaves (e.g. tsc --watch App.ts). By default it finds, compiles, and type checks imported files. You can disable this behavior with the --noResolve flag in which case it'll generate an error if you fail to include an imported file as input.

I propose that gulp-tsb's default behavior be to fully process all files it finds through imports during the initial build.

Documentation: readme should show option of passing a tsconfig.json file as input

First compile after full build triggers almost full build

Seeing this with "gulp watch" in VS Code. I wait until the full build is done and then I do a change anywhere in the workbench (e.g. console.log in workbench.ts). After that, almost a full build is triggered because gulp-tsb thinks the shape of lib.d.ts has changed:

[11:23:01] [tsb] time: 26158ms mem: 737MB Δ686
*** Finished with 0 errors.
*** Starting...
[11:23:59] [emit code] /Users/bpasero/Development/monaco/src/vs/workbench/browser/workbench.js
[11:23:59] [check syntax] /Users/bpasero/Development/monaco/node_modules/typescript/lib/lib.d.ts
[11:23:59] [check syntax] /Users/bpasero/Development/monaco/src/vs/workbench/browser/workbench.ts
[11:23:59] [check semantics] /Users/bpasero/Development/monaco/node_modules/typescript/lib/lib.d.ts
[11:23:59] [check semantics] /Users/bpasero/Development/monaco/src/vs/workbench/browser/workbench.ts
[11:23:59] [check semantics*] /Users/bpasero/Development/monaco/node_modules/typescript/lib/lib.d.ts is an internal module and it has changed shape -> check whatever hasn't been checked yet
[11:23:59] [check semantics] /Users/bpasero/Development/monaco/src/vs/workbench/services/files/node/watcher/win32/watcherService.ts
[11:23:59] [check semantics] /Users/bpasero/Development/monaco/src/vs/workbench/services/files/node/watcher/win32/csharpWatcherService.ts
[11:23:59] [check semantics] /Users/bpasero/Development/monaco/src/vs/workbench/services/files/node/watcher/typings/chokidar.d.ts
[11:23:59] [check semantics] /Users/bpasero/Development/monaco/src/vs/workbench/services/files/node/watcher/unix/watcherService.ts
[11:23:59] [check semantics] /Users/bpasero/Development/monaco/src/vs/workbench/services/files/node/watcher/unix/watcherApp.ts

gulp-tsb@3 refuses to output js files with allowJs

Since gulp-tsb removes the outDir compiler at

gulp-tsb/src/builder.ts

Line 61 in 35f134a

delete compilerOptions.outDir; // always emit relative to source file

TypeScript thinks that the output file is the same as the source file and reports as:

[error] Cannot write file '/Users/zenorbi/Desktop/test/src/test.js' because it would overwrite input file.
Adding a tsconfig.json file will help organize projects that contain both TypeScript and JavaScript files. Learn more at https://aka.ms/tsconfig.

TypeScript checks for this at https://github.com/Microsoft/TypeScript/blob/b1878e62bfeea57a926185e87449d89f34ba5742/src/compiler/program.ts#L2618 and can be suppressed by adding
options.suppressOutputPathCheck = true;
before

gulp-tsb/src/index.ts

Line 65 in 35f134a

const _builder = builder.createTypeScriptBuilder(config, options);

However this would use internal TypeScript options. Would you accept a PR for this?

Can't reuse config object for multiple compilations

var tsb = require('gulp-tsb');

var config = {
    target: 'es5',
    module: 'commonjs',
    declaration: false
};

var compilation1 = tsb.create(config);
var compilation2 = tsb.create(config);

// use compilation2

I noticed compilation2 will suddenly create a .d.ts file for each .ts file I have, which is a bit annoying.

I should be able to reuse the config object.

wrong transpiler result for "for..of" loop for Map.

Hi guys,
I am trying to use iterators with Map instance and I stumbled upon the issue

Code:

var myMap = new Map();
myMap.set(0, "zero");
myMap.set(1, "one");
for (var [key, value] of myMap) {
  console.log(key + " = " + value);
}

transpiles into:

var myMap = new Map();
myMap.set(0, "zero");
myMap.set(1, "one");
for (var _i = 0, myMap_1 = myMap; _i < myMap_1.length; _i++) {
    var _a = myMap_1[_i], key = _a[0], value = _a[1];
    console.log(key + " = " + value);
}

but Map does not have length property, intead it has size

can not compile project with es5 library on Windows

Checkout microsoft/vscode@51108dd

gulp watch-extension:json-client

Works on Linux and & Mac, fails on Windows:
Error: D:/work/3/s/extensions/json/client/src/jsonMain.ts(85,13): Cannot find name 'Promise'.

Do not work with "--allowJs" option

Typescript 1.8 support --allowJs, but gulp-tsb seems to ignore it.

var tsb = require('gulp-tsb');

// create and keep compiler
var compilation = tsb.create({
    target: 'es5',
    module: 'commonjs',
    declaration: false,
    allowJs: true
});

gulp.task('build', function() {
    return gulp.src(['src/**/*.ts', 'src/**/*.js'])
        .pipe(compilation()) // <- new compilation
        .pipe(gulp.dest('dist/'));
});

Correct output files are still generated for respective source *.ts, but none is generated for the *.js files.
It works correctly when running tscon the command line.

Duplicate of gulp-typescript

This plugin looks to be a duplicate of gulp-typescript. Because of that it has been blacklisted (gulpjs/plugins#187). Can you instead of creating your own version consolidate your work into gulp-typescript?

A difference I could find between gulp-typescript & gulp-tsb is that gulp-tsb will recompile only changed files. That can be dangerous as you can see in microsoft/TypeScript#3113. That's why it is not supported in gulp-typescript. If there are more features not supported by gulp-typescript, let me know, so that we can take a look at how these can be implemented in gulp-typescript.

Can't figure out how to glob only certain typings

With TypeScript 1.8.2 I'm using tsb with typings.

Typings looks like this -

- typings
|-- browser
  |-- ambient
    |-- # typings.d.ts
|-- main
  |-- ambient
    |-- # typings.d.ts

and when I run the gulp task it finds the duplicates in both directories. I'm trying to figure out how to exclude one or the other somehow without success yet, not sure if there is a configuration option for this or not with tsb or if it is a typescript compiler option. The process completes just get a ton of warnings.

Patch doesn't seem to have been applied

I nuked my node_modules folder and re installed to get gulp-tsb version 1.10.2. I see the same issue that #33 was supposed to fix.

This is what lib/index.js looks like in my node_modules folder.

function create(configOrName, verbose, json, onError) {
    var config;
    if (typeof configOrName === 'string') {
        var parsed = typescript_1.readConfigFile(configOrName, function (path) { return fs_1.readFileSync(path, undefined); });
        if (parsed.error) {
            console.error(parsed.error);
            return function () { return null; };
        }
        config = parsed.config.compilerOptions;
    }

Changing undefined to 'utf-8' solves the breaking error. Here is the error message I was seeing.

[09:40:07] TypeError: Cannot read property 'on' of null
    at DestroyableTransform.Readable.pipe (/Users/waander/Development/Microsoft/vscode-docs/out/vscode-website/node_modules/gulp/node_modules/vinyl-fs/node_modules/through2/node_modules/readable-stream/lib/_stream_readable.js:516:7)
    at Gulp.<anonymous> (/Users/waander/Development/Microsoft/vscode-docs/out/vscode-website/gulpfile.js:110:10)
    at module.exports (/Users/waander/Development/Microsoft/vscode-docs/out/vscode-website/node_modules/gulp/node_modules/orchestrator/lib/runTask.js:34:7)
    at Gulp.Orchestrator._runTask (/Users/waander/Development/Microsoft/vscode-docs/out/vscode-website/node_modules/gulp/node_modules/orchestrator/index.js:273:3)
    at Gulp.Orchestrator._runStep (/Users/waander/Development/Microsoft/vscode-docs/out/vscode-website/node_modules/gulp/node_modules/orchestrator/index.js:214:10)
    at Gulp.Orchestrator.start (/Users/waander/Development/Microsoft/vscode-docs/out/vscode-website/node_modules/gulp/node_modules/orchestrator/index.js:134:8)
    at /usr/local/lib/node_modules/gulp/bin/gulp.js:129:20
    at nextTickCallbackWith0Args (node.js:419:9)
    at process._tickCallback (node.js:348:13)
    at Function.Module.runMain (module.js:444:11)

passing a tsconfig.json path to tsb.create no longer works for typescript 1.8.x

In this case tsb.create(path) returns a nop compilation function that returns null.

tsconfig src files

Hi, just wondering how you would avoid hardcoding the values in the gulpfile.js file, so instead of the below compilation would read all the files from the tsconfig.json? Would also be nice if I could avoid the dest(...) call as well somehow as this is in the config as well.

    var tsb = require('gulp-tsb');

    // create and keep compiler
    var compilation = tsb.create({
        target: 'es5',
        module: 'commonjs',
        declaration: false
    });

    gulp.task('build', function() {
        return gulp.src('src/**/*.ts')
            .pipe(compilation()) // <- new compilation
            .pipe(gulp.dest(''));
    });

Edit:

a. I also wonder why these gulp typescript tasks don't just simply delegate to the TypeScript compiler.
b. Is there any chance of merging intogulp-typescript? As the latter seems to support what I was looking for, e.g., however the dest is still there...

gulp.task('scripts', function() {
    var tsResult = tsProject.src() // instead of gulp.src(...)
        .pipe(ts(tsProject));

    return tsResult.js.pipe(gulp.dest('release'));
});

Thank you,

New Release/Update vinyl dependency to >= 0.5.3

The latest PR already fixed what I'm after but there's not been a release since. Any chance of a published release?

The issue I'm facing is as follows:

[13:06:12] Error: Received a non-Vinyl object in `dest()`
    at DestroyableTransform.normalize [as _transform] (C:\Documents\Repos\oi\siopa-package-tools\node_modules\vinyl-fs\lib\dest\prepare.js:16:17)
    at DestroyableTransform.Transform._read (C:\Documents\Repos\oi\siopa-package-tools\node_modules\readable-stream\lib\_stream_transform.js:182:10)
    at DestroyableTransform.Transform._write (C:\Documents\Repos\oi\siopa-package-tools\node_modules\readable-stream\lib\_stream_transform.js:170:83)
    at doWrite (C:\Documents\Repos\oi\siopa-package-tools\node_modules\readable-stream\lib\_stream_writable.js:406:64)
    at writeOrBuffer (C:\Documents\Repos\oi\siopa-package-tools\node_modules\readable-stream\lib\_stream_writable.js:395:5)
    at DestroyableTransform.Writable.write (C:\Documents\Repos\oi\siopa-package-tools\node_modules\readable-stream\lib\_stream_writable.js:322:11)
    at Pumpify.Duplexify._write (C:\Documents\Repos\oi\siopa-package-tools\node_modules\duplexify\index.js:212:22)
    at doWrite (C:\Documents\Repos\oi\siopa-package-tools\node_modules\readable-stream\lib\_stream_writable.js:406:64)
    at writeOrBuffer (C:\Documents\Repos\oi\siopa-package-tools\node_modules\readable-stream\lib\_stream_writable.js:395:5)
    at Pumpify.Writable.write (C:\Documents\Repos\oi\siopa-package-tools\node_modules\readable-stream\lib\_stream_writable.js:322:11)
[13:06:12] 'buildTsEs2015' errored after 1.62 s

Hi,

Not really investigated this but I'm running into an issue when using gulp 4.0 and I think it's due to the following (from gulpjs/vinyl-fs):

yes, it was intentional because those versions are missing critical parts to the ecosystem. Vinyl 0.5.3 came with gulp-util, so that's what most people would be using. I might have been able to slip a 0.4.6 -> 0.5.3 change into vinyl-source-stream but I want people to upgrade to 2.0.0 so I don't really care to do that now.

I've not looked into this in any detail. Could the dependency be updated to at least 0.5.3?

Cmd+O proposes wrong folder

• be on mac
• git cmd+o

• it start with the folder that you have opened last (like, ~/dev/vscode) which is never a good choice because why would I open the folder which I opened last again? Instead it should open the folder from which I have opened the last folder (the parent of the current folder, ~/dev/)

tsconfig.json lib option doesn't work on windows

When I provide a "lib" field in tsconfig.json, it works as long as the OS uses slashes (/) as separator for paths. Typescript uses the LanguageServiceHost.getDefaultLibFileName as a way to get the location of the lib directory. On Windows the path will contain backslashes () . Typescript uses slashes internally and when it tries to get the directory from a path, it uses slash to find the last path component and failing to return the correct path.

gulp-tsb/src/builder.ts

Line 561 in 114c0da

return require.resolve("typescript/lib/" + libFile);

Typescript uses the getDefaultLibFileName as a backup, if getDefaultLibLocation is not available on the LanguageServiceHost. However, when Typescript gets the LanguageServiceHost from gulp-tsb, it wraps the object in a sort of proxy, which is missing the getDefaultLibLocation forward.

So a solution would be either:

1. Modify the getDefaultLibFileName to always return a path with slashes.
2. Implement the forwarding of getDefaultLibLocation in Typescript and implement the getDefaultLibLocation in gulp-tsb as well, using (or not) platform dependent separators.

I think number 1 should be the easiest and would also follow Typescript's way of using slashes on all platforms.

Version mismatching

Hi there,

      Why the version tagged in upstream not matches with npmjs version? 💭 

npm version => 4.0.5
github tagged latest version => 2.0.7

allowJs compiler option

I'm working on a fairly large project and we want to use this gulp plugin because the other one is far too slow. However, it looks like even with the --allowJs flag on the compiler, js files are ignored. I've been digging through this for a while now, and changed builder.getScriptFileNames() to accept js files:

getScriptFileNames(): string[] {

    const result: string[] = [];
    const defaultLibFileName = this.getDefaultLibFileName(this.getCompilationSettings());
    for (let fileName in this._snapshots) {
        if (/\.tsx?/i.test(path.extname(fileName))
            || /\.jsx?/i.test(path.extname(fileName))
            && fileName !== defaultLibFileName) {

            // only ts-files and not lib.d.ts-like files
            result.push(fileName)
        }
    }
    return result;
}

but now I get really strange errors by the typescript compiler:

.../project/node_modules/typescript/lib/typescript.js:48272

                throw new Error("Could not find file: '" + fileName + "'.");

even though that file is there (it only does this for js files). I feel like I'm in a little over my head, so I was wondering if anyone here has any idea what's going on?

Tag new version (4.0.5)

Please tag the new version 4.0.5 in this github repository, which is essential for packing this module to debian....

Request/favor - could the code be modularized to decouple from Gulp

I would like to use this module, but without Gulp. Would it be possible to do so?

I am using TSC but want to speed it up. tsc -w is pretty fast, but the problem is I cannot hook into it to see when it's done.

So I have tried creating my own tsc compiler watcher that I can control:

microsoft/TypeScript#13608
microsoft/TypeScript#14722

But I am having problems. I could just steal your code, but don't want to use Gulp if I don't have to. Maybe you could modularize it and decouple the transpilation code from the Gulp code. Please lmk, thanks!

Change the typescript dependency to a peerDependency

gulp-tsb currently has typescript as a dependency. This should be changed to a peerDependency. This avoids that 'hosts' of gulp-tsb end up having multiple and different versions of typescript installed in their setup.

See also tslint as an example https://github.com/palantir/tslint/blob/master/package.json#L42.

See also microsoft/vscode#2098 that initiated this.

Build with latest typescript throws errors

gulp build
[06:32:22] Local gulp not found in /<<PKGBUILDDIR>>
[06:32:22] Try running: npm install gulp
[06:32:22] Using globally installed gulp
"No inputs were found in config file 'tsconfig.json'. Specified 'include' paths were '[\"src\"]' and 'exclude' paths were '[\"lib/\"]'."
[06:32:22] Using gulpfile /<<PKGBUILDDIR>>/gulpfile.js
[06:32:22] Starting 'build'...
[06:32:22] Starting 'pre-build'...
[06:32:22] Finished 'pre-build' after 8.19 ms
[06:32:22] Starting 'buildWithPreBuild'...
[06:32:22] 'buildWithPreBuild' errored after 967 μs
[06:32:22] Error: Cannot find module './lib-prebuild'
Require stack:
- /<<PKGBUILDDIR>>/gulpfile.js
- /usr/share/nodejs/gulp-cli/lib/versioned/^4.0.0/index.js
- /usr/share/nodejs/gulp-cli/index.js
- /usr/share/nodejs/gulp/bin/gulp.js
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:815:15)
    at Function.resolve (internal/modules/cjs/helpers.js:80:19)
    at reload (/<<PKGBUILDDIR>>/gulpfile.js:62:22)
    at buildWithPreBuild (/<<PKGBUILDDIR>>/gulpfile.js:28:15)
    at bound (domain.js:427:14)
    at runBound (domain.js:440:12)
    at asyncRunner (/usr/share/nodejs/gulp/node_modules/async-done/index.js:55:18)
    at processTicksAndRejections (internal/process/task_queues.js:79:11)
[06:32:22] 'build' errored after 11 ms

Documentation: explain how sourceMaps should work

It seems like this module doesn't work with gulp-sourcemap. That's OK, but that should be reflected in the README.

support electron d.ts files without errors

I have an electron project where some files reference github-electron-main.d.ts and others reference github-electron-renderer.d.ts and when I compile with tsc, I don't get any errors. But, when I use gulp and gulp-tsb, I get:
Duplicate identifier 'export='."
Duplicate identifier 'export='."

reported once for each file. It looks like typescript's compiler supports this, but tsb somehow breaks the functionality.