This repository has been archived by the owner on Aug 19, 2019. It is now read-only.
Add emission of published files #57
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This adds an option to emit published files, along with associated configuration changes. The constants file receives a number of new default values for options related to this feature. The command builder uses these options to extend the properties object if the emitPublishedFileds option is true. Note that the PublishUrl defaults to a uuid.v4. Finally, the msbuild-runner library is updated to emit the published files if the emitPublishedFiles flag is true. In order to do this, it needs access to the top level through2 stream that this plugin creates. To accomodate this, the call to startMsBuildTask now accepts a stream parameter, which allows us to pass the through2 stream down and have files emitted by it. This also requires updates to the unit tests, in order to accomodate the change of parameter order.
This changes the publishUrl option to be called publishDirectory, based on the naming discussed in the issue that I raised around this. This also moves the assignment of a default value to the constants.js file instead of in the command builder.
This adds a simple test that ensures that when the emitPublishedFiles option is set to true, the correct msbuild command is generated.
This adds some proper unit tests that test our new functionality. Based on these tests I fixed a few small typos and logic errors. There's still a todo here that needs some work. I'm not really sure why I can't get the calledWith assertion to work on the objects passed to mockStream.push, but I would like to have proper coverage there before merge.
This adds a working unit test for the stream push. We also point to the correct location of the publish directory on the options object.
We don't need to join the path to the destination, since our glob now returns the absolute path of the generated file.
Since the glob function is asynchronous, we don't want to call the callback until it has finished executing. With the callback in the original location, the stream was emitting the end event before the glob had pushed files into the stream. This correctly puts the call to the through2 callback inside the glob callback, and updates the unit tests accordingly.
2 similar comments
|
Apologies, this should probably be a PR into develop |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds an option which allows you to emit published to the stream. This is incredibly useful because it neatly encapsulates publishing your code to a temporary directory and then returning a stream of the published files. This makes it easy to pipe the stream into other gulp plugins to perform further work on the published files.
As discussed in issue #46, this adds the following functionality:
emitPublishedFilesoption which causes the published files to be emitted by the plugin. Setting this to true causes the required msbuild options to be added to the msbuild command that enables a filesystem publish to a the provided directorypublishDirectorywhich controls where the files are published to on the filesystem. If this option is not specified, the publishDirectory defaults to a directory inside the system temp folder, with a folder name based on a uuid v4I have added some unit tests of this functionality, but feel free to suggest more.