Rocket.Chat WebHook with Typescript

Question

im about to write a complex Incoming WebHook for Rocket.Chat. To avoid a mess in one single file i took Typescript. Rocket.Chat requires a class named Script with some predefined methods like process_incoming_request (one simple example: https://rocket.chat/docs/administrator-guides/integrations/).

my current project setup looks like:

tsconfig.ts

{
  "files": [
    "src/main.ts"
  ],
  "compilerOptions": {
    "noImplicitAny": true,
    "target": "es2015"
  }
}

gulpfile.js

var gulp = require("gulp");
var browserify = require("browserify");
var source = require("vinyl-source-stream");
var tsify = require("tsify");
var uglify = require("gulp-uglify");
var buffer = require("vinyl-buffer");

gulp.task(
    "default",
    function () {
        return browserify({
            basedir: ".",
            debug: true,
            entries: ["src/main.ts"],
            cache: {},
            packageCache: {}
        })
            .plugin(tsify)
            .transform("babelify", {
                presets: ["es2015"],
                extensions: [".ts"]
            })
            .bundle()
            .pipe(source("bundle.js"))
            .pipe(buffer())
            .pipe(uglify())
            .pipe(gulp.dest("dist"));
    }
);

main.ts

import {RequestInterface} from "./Interface/RequestInterface";

class Script {
    process_incoming_request(request: RequestInterface) {
        // some code
    }
}

The yarn gulp process runs smoothly without errors but when using the generated code inside the script part of the webhook it results in an error:

Incoming WebHook.error script.js:1   
ReferenceError: module is not defined       
at script.js:1:4307       
at Script.runInContext (vm.js:127:20)       
at Script.runInNewContext (vm.js:133:17)       
at getIntegrationScript (app/integrations/server/api/api.js:70:12)       
at Object.executeIntegrationRest (app/integrations/server/api/api.js:166:13)       
at app/api/server/api.js:343:82       
at Meteor.EnvironmentVariable.EVp.withValue (packages/meteor.js:1234:12)       
at Object._internalRouteActionHandler [as action] (app/api/server/api.js:343:39)       
at Route.share.Route.Route._callEndpoint (packages/nimble_restivus/lib/route.coffee:150:32)       
at packages/nimble_restivus/lib/route.coffee:59:33 

Im not that familiar with Typescript, Node and all the stuff. So the main question is, how can i achive that the process generates a class (or a script which exposes a class) named Script with the method process_incoming_request. Im also not sure if my script generates the error or the RocketChat part.

Thanks!

Answer 1

I guess the problem is that Gulp (or some of it's plugins) generates a scaffolding code, necessary for JS's (non-existent) module system, and it often implies wrapping the compiler output into weird multi-layered anonymous functions.

If you don't need any kind of module system and just want your multiple TS files translated directly to a single JS file (which supposedly goes to the RocketChat), then I'd suggest ditching Gulp altogether, letting TSC to compile your code as usual, then bundling the resulting .js files into a single one with a script.

So, the overall setup would be as follows (assuming src is a source code folder):

tsconfig.json

{
  "include": [
    "src/**/*.ts"
  ],
  "compilerOptions": {
    "noImplicitAny": true,
    "target": "es2016"
  }
}

build.sh

#!/bin/bash

# TSC puts compiled JS files along with their TS sources. 
node_modules/typescript/bin/tsc

# Creating an empty bundle file.
echo "">dist/app.js

# Bundling all the JS together.
# sed removes the 'export' keywords & 'import' statements.
while read p; do
  cat $p | sed -E "s/^export\s+(class|function|async|const|var)/\1/" | sed -E "s/import.*$//" >> dist/app.js
done <<< $(find src -type f -name "*.js")

So you program your thing as usual, build it with ./build.sh, get the dist/app.js file and use it in RocketChat.

There must be a way to do something along these lines in Gulp, but I'm not familiar with it, and don't think a full-blown build system is really needed here.