Sp-dev-docs: Yeoman generator does not correctly implement the update-notifier API

Created on 16 Sep 2016 · 5Comments · Source: SharePoint/sp-dev-docs

Expected or Desired Behavior

In general yeoman generator notifies when new version is avaiable right before a new project will be started. In generator-sharepoint it is the other way round.

I create a project last night and it fully provisioned after I got the following notification.
screen shot 2016-09-15 at 23 34 02

Please put yeomans default update-notifier in right order. Thank you.

tracked bug-suspected

Source

StfBauer

Most helpful comment

@estruyf yes that's true but it should be placed before the generator start working not at the end. Because i create a project that I have to delete because it's the old version.

@patmill The only thing that needs to be done in the index.js of the generator is to move line 13:

updateNotifier({ pkg }).notify();

inside the initializing or constructor to disable the defautl defer to the end of the thread:

    var update = updateNotifier({ pkg });
    update.notify({defer: false}); // turns defer to false

Especially with this generator it's important that the message comes at the beginning becaue when you update the generator and run it again you will create a new web part maybe.

StfBauer on 16 Sep 2016

👍3

All 5 comments

@StfBauer that seems to be the default behaviour of the update-notifier.

Whenever you initiate the update notifier and it's not within the interval threshold, it will asynchronously check with npm in the background for available updates, then persist the result. The next time the notifier is initiated the result will be loaded into the .update property. This prevents any impact on your package startup performance. The check process is done in a unref'ed child process. This means that if you call process.exit, the check will still be performed in its own process.

So it will notify you the next time you run the generator.

estruyf on 16 Sep 2016

We are working on an environment validator. Making sure this is covered as well.

patmill on 16 Sep 2016

@estruyf yes that's true but it should be placed before the generator start working not at the end. Because i create a project that I have to delete because it's the old version.

@patmill The only thing that needs to be done in the index.js of the generator is to move line 13:

updateNotifier({ pkg }).notify();

inside the initializing or constructor to disable the defautl defer to the end of the thread:

    var update = updateNotifier({ pkg });
    update.notify({defer: false}); // turns defer to false

Especially with this generator it's important that the message comes at the beginning becaue when you update the generator and run it again you will create a new web part maybe.

StfBauer on 16 Sep 2016

👍3

This has been fixed.

nickpape on 5 Jan 2017

👍2

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues