Gulp task

[stimms]

I see there is a grunt task for running tests but I didn't see an equivalent gulp task or anything in the backlog here to create one. I sure would find one useful as would, I'm sure, many other people.

[phated]

There's no real reason to create a gulp task, as the grunt task just spawns a child process. Gulp lets you do that with standard node libraries

[sholladay]

+1

I do weird things like compute the user's name and overwrite the config file on disk just to shove it into capabilities.name, which helps a ton on my development team to keep track of issues on BrowserStack and understand where they are coming from. I am hoping the vinyl-fs approach in Gulp could be leveraged to speed this up by avoiding multiple file reads.

Even if this cannot work, it would help to have a clean, configurable API maintained and supported by Intern for how it wants to manage the child process, and which is dead simple to drop into a build system.

[phated]

@sholladay creating a plugin for this goes against the gulp plugin guidelines, using vinyl-fs as a globbing mechanism is an anti-pattern.

[stimms]

I made a first pass at implementing this at https://github.com/stimms/gulp-intern but it is very rough

[sholladay]

@phated almost every single competitor to Intern has a Gulp task.

• QUnit
• Mocha
• Jasmine
• Buster
• Karma
• Nightwatch

In addition, most of these are official plugins from those projects and listed at gulpjs.com/plugins.

On top of that, they get plenty of use and are a critical part of any build process.

So why not Intern? Why does Intern, specifically, not belong in the Gulp ecosystem? I have seen people use this line before, elsewhere, without giving alternatives that are better (in my mind, the DIY approach is not better). Even if there is a decent explanation, it sounds like an issue that should be addressed within Intern itself.

So where is the disconnect here? We want a test system and we want a build system, are we simply fools for wanting a bridge between the two that doesn't have to be maintained in-house, per-project? Which part of this use case is illegitimate and why?

[phated]

@sholladay the plugins site isn't a representation of plugins that follow the guidelines, just ones that people have published with the gulpplugins tag. Thank you for pointing all those out, I will take a moment to add them to our blacklist. We don't always have time to go through the list and add things to the blacklist.

If a library's API doesn't need file contents passed in, then there is no reason to make a gulp plugin. Test runners operate on file paths, not contents and therefore shouldn't be put in the middle of a stream. Gulp isn't some magic library where everything should be part of a stream, it just enables you to write tasks in JS.

[stimms]

So for the scenario where I'm building javascript using TDD practices what's the approach to take when using intern? I would really like to hook it into my gulp watch task and it would be nice if it didn't run my whole test suite but just a subset, perhaps just those in that module. For my code there is a pretty strong relationship between directory structure and module structure.

[phated]

@stimms the biggest problem with that is that you would need to programmatically set the file paths you wanted to test for the suite. Having a gulp task wouldn't solve this for you, as intern is configured with a file as far as I can tell.

[stimms]

The configuration file is json based so there doesn't seem to be a huge technical barrier to prevent writing a configuration file and passing it in or allowing intern to read overrides from the command line/environment. Managing the overrides seems like an ideal use of gulp

[phated]

@stimms gulp plugins are about streaming files through a set of transforms, not globbing and then writing to the filesystem, there was a good article on what belongs in a gulp plugin but I can't seem to find it. (I really dislike discoverability on Medium)

[stimms]

So your objection is that philosophically we're not following the proper conventions for how streams work in gulp?

[sholladay]

In fairness to me, that avoided many of my questions, but good to know about the plugins site.

To be clear, I'm suggesting precisely that Intern consume the contents of a file as part of its task. We desire to read and manipulate it without writing back to the disk only to have Intern read it back again later. In fact, it could be re-used by another mode (intern-client vs intern-runner) as well in another build step, so that's not the end of the road for it. The task could sanitize it and continue to pass it along, etc. and it would be super useful.

But if this isn't enough transformation, then you better get rid of JSLint, JSHint, ESLint, and JSCS on the plugins site, because they do none.

[kitsonk]

@phated @stimms @sholladay considering this has turned into a philosophical conversation about gulp, maybe there is a better forum than Intern issues?

[brianmhunt]

I would agree that a plugin is unnecessary. That said, it is probably worthwhile for the project to note in the docs the canonical way (or a few options) to get Intern running when using gulp as the task runner.

[morenoh149]

Indeed. I see the docs mention Grunt and I immediately wonder how to achieve similar functionality with an existing project using Gulp. If a plugin is unnecessary then documentation for adding Intern to a Gulp-using project should be added. Something like a watch task that reruns the test suite on the changed files. I'd be happy to submit a PR if that is the consensus.

Could I be pointed to the source for https://theintern.github.io/intern/ page?

[brianmhunt]

@morenoh149 By convention the source should be at https://github.com/theintern/intern/tree/gh-pages

[jason0x43]

There is now documentation for this at https://theintern.github.io/intern/#gulp. This issue can be reopened if that's not sufficient.