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.
We've received a couple reports (gh-3316 and gh-3318) that the installation size of JSHint increased drastically in the recently-released version 2.9.6. This is easily verified using npm's
--production
flag:Output:
Two independent commits contributed to this 20-fold increase in side. This patch addresses each of them in turn. You can verify using the same technique:
Output:
The final size is still twice that of the prior release, but that is due to the upgrade to Lodash 4 (gh-3260 and gh-3283).
Since that was motivated by security concerns, I'm more willing to accept the size increase. If this continues to be a concern for our consumers, we can consider instead relying on Lodash's sub-components.
Also of interest: the
remove-dev-dependencies.js
introduced here is not technically necessary on TravisCI because JSHint can now be successfully be installed in TravisCI on Node 0.8 and 0.10. That's surprising because this was all motivated by failures in TravisCI back in November. At first, I thought that maybe the maintainers ofrequests
had changed their tune, but no such luck. TravisCI now pre-installs PhantomJS, so the offending ES2015 code (used to fetch the binary) is no longer evaluated on any GNU/Linux build. However, we're not so lucky in the AppVeyor-provided Windows environment (and even if we were, we probably shouldn't rely on implicit aspects of the build environments). That's why I've written a script to manually remove the offending packages prior to installation in CI.I'd like to release a new version (i.e. 2.9.7) for this changeset so that we can help our consumers avoid the inefficiency as soon as possible.