Migrate tooling to TSC/NPM without Gulp dependency - question

[peterblazejewicz]

Hi folks,

I've create a single commit in mirror fork that replaced Gulp and related plugins with simple tsc compiler, tslint and just NPM scripts.
https://github.com/peterblazejewicz/SpeechToText-WebSockets-Javascript/commit/5209385ee43b25db324bb6406a4e414498be7bf3
Would you be interested in taking this into consideration?
The output produces one additional file as the maps are generated for non-minified and minified version of transpiled JavaScript file.
Also the d.ts has comments - as it appears anti-DX to not ship comments with code (when stripped out, the VSCode will not provide docs from original source file)

Thanks!

[raaaar]

Hey. What are the upsides of not using gulp? Also, what do you mean by 'anti-DX'?

[peterblazejewicz]

What are the upsides of not using gulp?

Simpler build chain: single config file package.json, quicker development install (only tools required to transpile, minify and clean).

I meant using power of IDE to guide someone writing a code:

Here is an exported type with comments left:

and here is one without comments:

When the comments (JSDco/TSDoc) are left in type definition file, they are picked by IDE - unless the project is using original source file imports.

Thanks!

[rcollette]

In a production application we are able to remove hundreds of lines of build code moving to npm scripts. The build here is one line of statements. On the build server, since these are command line statements, you can see exactly what commands are running the build. You are less dependent on additional modules required to run in gulp (which sometimes introduces additional bugs or lags the command line tooling). Take a hard look at it and you will see the benefits.

[raaaar]

As far as the API documentation comments go, totally makes sense to keep those.

WRT gulp vs npm scripts argument, I'm not convinced. Development install: one-off +/- 30 seconds, not a big issue. With gulp you have most build configs in one place, with npm you'd have to have a separate tsconfig.json, webpack.config, etc.

Not sure, I understand how the "readable build server stdout" argument applies to this sdk. This codebase is fairly small, so it makes very little difference what specific build tool is used to compile and package it.

[peterblazejewicz]

Cory House has nice article on the Gulp/Grunt subject:
https://medium.freecodecamp.org/why-i-left-gulp-and-grunt-for-npm-scripts-3d6853dd22b8

For me the Gulp just hides configuration and prevents people from improving things. The tsc configuration file is tsconfig.json.

My goal here is to overhaul the build process and make Bootstrap development more approachable to everyone (myself included)

twbs/bootstrap#20332 (comment)

The point of my question in PR was to make this project simpler and easier to grasp for the users.

Thanks!

[raaaar]

We've just switched to commonjs modules, as a result tsc produces a bunch of separate js sources that need to be glued together with something like a webpack. NumConfigs++. TSLint needs a config. NumConfigs++. So, you might as well say that npm scripts hide complexity by pushing it into tool-specific configs.

At any rate, I'm not trying to argue with whatever is currently the trending build philosophy in the JS community. It might make total sense in a large project, in the context of this sdk, it feels more like putting cover sheets on the TPS reports.

That said, I would appreciate a PR with this commit, to keep it on the back burner in case there's a blocker with gulp.

[rcollette]

Those config files drive ide assistance such as edit time lint warnings. But if you're running a team that is larger than the community editing this library and it's a better flow for you without them, then you you can't argue with that.