don't do extra steps in build so things are faster in the normal case #31
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
|
LGTM, travis will clean so I don't have too!! (@jmazzitelli cookie for the ref) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
I propose we do not do anything extra in the build target. I'm removing both clean and format as dependent targets on build for the following reasons:
format - we now have a pre-commit hook that will format the files for you on commit. Thus, there is no need to always format on build which is inefficient. The developer has options here - he can set up his IDE to always format on save (most devs do this) or they can "make format build" on the command line if they want to format during the build. By removing format dependency on build target, we don't force a format for EVERY build for EVERY developer.
clean - if we clean on every build, it deletes the UI code we installed in _output/npm. This has the detrimental effect of always forcing the user to download again (via npm install) the UI code which takes a long time (in some cases half a minute, and when the UI code gets larger, that time will only grow). Thus to avoid having to npm install everytime a dev wants to do a code-deploy-test cycle, we should not perform a clean on every build. If a developer wants to perform a clean build, the option is available by simply running "make clean build".
In short, this PR is to allow the build and test cycle to be faster for the normal case.
Note this PR also ensures travis only has to build once.