"fail" updateType and "skip" options

[lukemadera]

Firstly, great plugin,thanks @pgilad ! I have one (hopefully small / not too difficult) suggestion / request - adding a "fail" option as well as "report", "prompt" and "force" since I want to use this to ensure we're always up to date BUT often packages go through breaking changes so I don't want to just automatically update them (with "prompt" or "force") if they're out of date. I do want to fail the grunt task though.

The second request would be to then allow skipping a defined array of certain packages if we want to keep them out of date for whatever reason to allow the grunt task to pass (i.e. for continuous integration and building in case we need to release before updating a particular package). This may be a more complicated and time consuming feature so I'm happy to break it into a separate feature request; the urgent one right now is just a way to fail the grunt task if things are out of date so we can manually update them (rather than automatically in case there are any breaking changes in that update that would break the app). Knowing when things are out of date is super useful but auto updating seems dangerous and error prone.

Thanks so much!

[pgilad]

I'll take a look when I have some time. PR are obviously welcomed ;-)
We have 2 feature requests here:
updateType: fail

and ignoredPackages which is an array of packages to ignore. Should those ignored packages be checked for newer version, or just totally skipped?

[lukemadera]

Yep! For ignoredPackages I hadn't really thought about it but for me at least it doesn't matter as long as they don't fail the task (whether they're checked or just totally skipped). I suppose more info is better so info could be output - perhaps an "ignored" section of output and/or another option to toggle complete skipping.

And yeah, I'll see if I can get to a PR and if so I'll let you know! Thanks again!

[pgilad]

Will try to add ignoredPackages soon...

[pgilad]

hi @lukemadera thanks for the ideas!

I've added both the option fail to updateType, and also a new option reportOnlyPkgs which is an array that holds package names that will at most be reported for being updated.

Cheers! 🍺

[lukemadera]

You're awesome @pgilad many thanks for the speedy reply and update! 2 comments:

1. fail works great but would it be possible to still output all the outdated ones and THEN fail? I.e. right now it aborts on the first one - which works BUT makes it difficult to then update them since you can only see/update one at a time. In practice I could make a 2nd task that's for reporting only but it would be nice to be able to do it all in one task.
2. reportOnlyPkgs doesn't seem to be working for me - I have the following config:

dev: {
                    options: {
                        packages: {
                            devDependencies: true,
                            dependencies: false
                        },
                        updateType: 'fail',
                        reportOnlyPkgs: ['grunt-contrib-less']
                    }
                }

Yet grunt-contrib-less is still failing it. Is my config incorrect or am I misunderstanding something?

Thanks again!

[pgilad]

If you choose updateType=fail then that is tested first and over-rides any skipping behaviour.

Try using reportOnlyPkgs with updateType!==fail.

Regarding the fail option, yeah it could easily be changed to fail the task after reporting all the outdated packages, but then updateType is actually report and not fail and that needs to be a separate option..

So they are 2 options as to how to design this:

1. Fail on first outdated task
2. Fail at end of task if any task was outdated (disregarding any action that was taken on outdated tasks)

Since you are the feature requestor I'll let you choose...

@lukemadera?

[lukemadera]

Gotcha. So I was only ever planning on using reportOnlyPkgs with the updateType fail option - the idea was to fail the grunt task if there were out of date packages to force a (manual) update of the out of date packages. BUT allow the option to set/allow some packages to be out of date. So yes, fail would be exactly like report except it would fail the grunt task at the end. reportOnlyPkgs would be exceptions and would NOT cause the grunt task to fail. All outdated tasks would always be reported and displayed. That's what I was after.

That said, I'm not sure how urgent it is - it may actually be worse to force manual updates via the fail option since that could incentivize just adding the out of date packages to reportOnlyPkgs to skip them and that could lead to more problems later. So as of now the report updateDate actually seems to be fine.

In short: an option similar to your option 2 could be nice but maybe isn't necessary. So perhaps we can just close this issue - sorry for any trouble/back and forth! Though thanks for the super fast replies and updates - much appreciated @pgilad !!

[pgilad]

No problem... You could as you said add a target that only reports outdated packages, and another task that updates all packages but skips the critical packages you want to manually open.

So you first run grunt devUpdate:updatePackages and then if you just want to report outdated packages you can run grunt devUpdate:reportOnly.

Off course you need to setup those targets but that's easy and you can just use defaults for most stuff.

Another thing is you can create a task that runs both these commands so ['devUpdate:updatePackages', 'devUpdate:reportOnly'] and that could be run with a single command to both update all your non-critical packages and then report the outdated packages

[lukemadera]

Sounds good, I'll close this issue for now accordingly, thanks again!