-
Notifications
You must be signed in to change notification settings - Fork 170
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
Have nonull: true
cause the task to warn and abort.
#106
base: main
Are you sure you want to change the base?
Conversation
This fix just saved me in my own project. Please give this request some attention. Thanks. |
+1 for this change, saves my life. Really would like to see this upstream. |
@jacksonrayhamilton: you have many unrelated changes in this branch. You should rebase and clean it up. Then, someone might actually be able to have a look. |
@jacksonrayhamilton can you get back to this? 👍 |
249f183
to
ea72121
Compare
Cleaned it up. |
The branch still has unrelated changes.
|
@XhmikosR, I don't understand, what is unrelated? |
You should just have the fail warm change and not all other stuff. If you
|
There was a limitation in the way the tests were set up. As I explained,
I wanted to actually know that the task failed and aborted. But normally a failing task would cause the whole test suite to fail, as the very intent of this pull request is to make a chain of grunt tasks fail! Thus I had to sandbox the failure inside a child process. |
👍 Can you fix the merge conflict? |
ea72121
to
07410e0
Compare
@jacksonrayhamilton Any chance you proceed on this anytime soon? Thanks in advance! 👍 |
I believe this PR should supersede this one. It solves the same problem in a strictly backwards-compatible way with only six lines of code. Any chance we can get some movement on this? |
Hey guys, sorry that this issue got abandoned. I totally forgot about it since I haven't been using this package as much as I used to. @tkambler, I do like that your solution is backwards-compatible. I don't think it's fair to say that it's a lot simpler, since it doesn't include tests or documentation. But if you added those things, I would definitely be in support of your change over this one. |
It looks like this has been a visible issue for some time. There was discussion about adding a There was also a discussion about whether tasks should fail or warn: gruntjs/grunt#1163 It also wasn't resolved, but it took place several years ago, so unless the grunt authors want to chime in, I think it's about time we took action. It was said that the ideal behavior would be, "A task should fail on anything that prevents it from accomplishing its primary task." I suppose it's true that "a concatenated file could still be made even if some files were missing," but it doesn't seem true that "the concatenation of a set of files can include only a subset of the files." In the latter case, which seems more pressing to me, this PR is probably correct, even though it might be a breaking change. |
07410e0
to
4d5f6b6
Compare
On Node.js 0.10 on Windows, due to this issue, concatenated files were still being generated even when the task was instructed to fail. (This is why that test was failing on Appveyor.) Added an unsightly workaround for it. Certainly open to other ideas for that fix. Might be something that should handled in the main |
Bump. Anyone still interested in this? |
sure |
Previously, specifying
nonull: true
would only cause the task to log a warning about a file being missing. This change modifies the task to issue a "real" warning and abort the task chain.It is rather nasty when concatenation skips over a file because you forgot to include it in your project. Say a developer is using
bower link
to develop some bower packages and is concatenating all his libraries into avendors.js
file. On a fresh clone he might forget to runbower link package-name
, and then be confused by the fact thatvendors.js
is generated but is missing a package.The current behavior of
nonull: true
begins to solve this problem, unless you have a long list of tasks and the warning gets buried in your console history. Having a warning at the tip of your console history immediately alerts you of a potential issue. Also, considering you specified thenonull: true
option, you have acknowledged that some paths have the potential to not match and would really, really like to know if they don't.I imagine it may have been difficult to test this functionality before (if anyone had ever desired it) because the current set of tests analyze the output of the main Gruntfile's
initConfig
concat
. I was able to test warnings and task-abortion by analyzing thestdout
ofchild_process#exec
.Please consider this pull request. I believe that fail-fast functionality is much more efficient for development.