Support multiple unit test frameworks ~40

[phillipskevin]

If possible, the generator should prompt the user for what unit test framework they'd like to use and then remember this selection when generating future components, models, etc.

[phillipskevin]

Another option would be to create a plugin for the other frameworks so someone could run donejs add jasmine or donejs add mocha. Then the generator would just need to look at which test framework is a dev dependency and create the tests accordingly or prompt the user if there are multiple options.

[daffl]

I was thinking about that, too but I'm not sure how it would work with donejs add. 1) An app would come without a unit-testing framework by default which is probably not what we want 2) Somehow when running another generator the added unit testing framework generator needs to know about it and create the appropriate files. This means maintaining two different repositories that technically belong together.

I think having test files for each framework in this repository is probably the easier approach.

[phillipskevin]

Yeah, I was thinking about the same issue. It would end up with having the same test templates in two different projects. If we put everything in this repository, the only other issue is deciding how to determine which template to use when someone runs a generator. We could either 1) prompt the user every time 2) determine based on devDependencies 3) keep track of the preference in a .donejsrc or similar

[daffl]

We already are storing some configuration in .yorc (this.config.set and this.config.get). We can probably just put it in there and, then read it and copy the proper template file.

[phillipskevin]

Oh, right. That makes sense.

[justinbmeyer]

Somehow when running another generator the added unit testing framework generator needs to know about it and create the appropriate files. This means maintaining two different repositories that technically belong together.

We could sort of aspect-oriented-programming this. Basically, a plugin could hook into other generators.

For example, the done-qunit plugin could hook into add component and add supermodel and write out its own files.

Say other generators get created outside "core" DoneJS generators like add custom-element. Someone could hopefully make a done-super-qunit plugin that would use the base done-qunit, but also add hooks to add custom-element.

[phillipskevin]

Would it be crazy for the generators to store their templates within the project? Say when you do donejs init it would create a .templates folder or similar and write out all of its templates there. Then if you ran donejs add qunit it would overwrite .templates/component/modlet/component_test.js and .templates/supermodel/model_test.js and whatever other files it needs to.

[daffl]

That is a great idea! That way people can modify their templates super easy, too. Lets chat about it some time today.

[marshallswain]

Yes! Huge vote for templates being inside the project.

[justinbmeyer]

@phillipskevin That's a good idea. I think slightly better might be having those generators as a separate project installed via NPM. We should be encouraging people to create a donejs-acme-component generator that other people could use. I don't want cool generators inaccessible to other projects.

[phillipskevin]

@justinbmeyer I'm not sure what you mean. I'm proposing that the generators store their templates within the donejs project. Then generators could overwrite templates created by other generators. All of the generators would still be projects installed via npm.

[cherifGsoul]

I find @phillipskevin's .templates idea is great, I wonder if we can adapted for https://github.com/donejs/donejs/issues/562 ?

[phillipskevin]

@daffl has already moved the templates so plugins can overwrite them in https://github.com/donejs/generator-donejs/pull/111. I agree this could also be used for choosing the module format, but we'll have to figure out how these will work together. For instance, how would you handle a user running donejs add mocha and then donejs add commonjs?

The donejs-commonjs plugin could use codemods (with something like https://github.com/facebook/jscodeshift) to modify the module format of the templates in place instead of overwriting them. This would require that the module format plugin be added after any other plugin that modifies the templates though.

[phillipskevin]

There is already a codemod library that can turn CJS modules into ES6 modules: https://github.com/5to6/5to6-codemod. This probably won't actually work though, since it is supposed to convert AST->AST and our templates won't be valid ASTs. We could still do it using regex though (probably?).

[cherifGsoul]

thank you @phillipskevin Im looking into that, just my idea is not to use donejs add commonjs is just to keep the info as user perference to use CJS or ES6 and generate files base on that

[justinbmeyer]

Stealjs/transpile does exactly this

Sent from my iPhone

On Apr 20, 2016, at 9:22 PM, Kevin Phillips notifications@github.com wrote:

There is already a codemod library that can turn CJS modules into ES6 modules: https://github.com/5to6/5to6-codemod. This probably won't actually work though, since it is supposed to convert AST->AST and our templates won't be valid ASTs. We could still do it using regex though (probably?).

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

[phillipskevin]

@justinbmeyer doesn't it only transpile to AMD though? Also, would it work on template ejs files that aren't valid JS?

[justinbmeyer]

@phillipskevin https://github.com/stealjs/transpile transpiles from and to everthing (except for to ES6, but if everything is written in ES6, this isn't a big deal).

It's not clear what ejs files would have to do with this? They wouldn't be using a module format to define dependencies. Templates would presumably use <can-import>.

I wonder if this approach is the right one as it doesn't scale great with many overlapping transformations.

A better, but probably more difficult toolset would be a bunch of transpiling add-ons that could take QUnit syntax and convert it to Jasmine or Mocha, take ES6 and convert it to CJS or AMD.

stealjs/transpile actually makes transpiling pretty straightforward. Here's an example:

https://github.com/stealjs/transpile/blob/master/lib/cjs_amd.js#L16

It basically looks for when the ast looks like require() and then converts that to define([]).