Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Grunt task #813

Closed
wants to merge 1 commit into from
Closed

Conversation

bryanforbes
Copy link
Member

  • Allow grunt options to specify 'config' to point to a config file and/or section
  • Change node/util.getConfig to accept an optional second argument to allow passing in other command line arguments
  • Updated task tests

Fixes #812

* Allow grunt options to specify 'config' to point to a config file and/or section
* Change node/util.getConfig to accept an optional second argument to allow passing in other command line arguments
* Updated task tests

Fixes theintern#812
@bryanforbes bryanforbes requested a review from jason0x43 October 10, 2017 20:28
@codecov-io
Copy link

codecov-io commented Oct 10, 2017

Codecov Report

Merging #813 into master will increase coverage by 0.01%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #813      +/-   ##
==========================================
+ Coverage   93.02%   93.04%   +0.01%     
==========================================
  Files          54       54              
  Lines        4347     4358      +11     
  Branches      943      945       +2     
==========================================
+ Hits         4044     4055      +11     
  Misses        303      303
Impacted Files Coverage Δ
src/lib/node/util.ts 96.92% <100%> (ø) ⬆️
src/tasks/intern.ts 100% <100%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e543ba5...ed79b44. Read the comment docs.

@@ -48,15 +48,15 @@ export function expandFiles(patterns?: string[] | string) {
* Get the user-supplied config data, which may include command line args and a
* config file.
*/
export function getConfig(file?: string) {
export function getConfig(file?: string, argv: string[] = process.argv) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We shouldn't need the string[] type since it can be inferred from the default arg. Also, should we have an overload that takes just an argv?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'd also be nice to add typedoc @param comments so we can point out that argv args should at position 2.


interface TaskOptions extends grunt.task.ITaskOptions, Partial<Config> {
[key: string]: any;
}

function configure(options: TaskOptions): Promise<{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

configure is a weird name for this since its not configuring anything (although I don't suppose it matters since its internal). Also, Intern code typically has things like module-level constants and functions declare below exports.

}> {
if (options.config) {
return getConfig(options.config, []).then(({ config }) => {
delete options.config;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of deleting config from the passed-in options, it'd be nicer to return a new object that didn't have the config property (since we're returning options anyway).

@@ -46,15 +55,15 @@ registerSuite('tasks/intern', function() {
},

beforeEach() {
mockRun.reset();
sandbox.reset();
mockRun.resolves();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we made mockRun = sandbox.stub().resolves(), could we get buy with just calling sandbox.resetHistory() above (instead of sandbox.reset())?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are a few other stubs I've set up that need to be reset every time

@jason0x43
Copy link
Member

Merged in def6346

@jason0x43 jason0x43 closed this Oct 13, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants