Change:
# --description-- <del> The last part of setting up your GitHub authentication is to create the strategy itself. For this, you will need to add the dependency of 'passport-github' to your project and require it in your `auth.js` as `GithubStrategy` like this: `const GitHubStrategy = require('passport-github').Strategy;`. Do not forget to require and configure `dotenv` to use your environment variables. </del> <ins> The last part of setting up your GitHub authentication is to create the strategy itself. For this, you will need to add the dependency of `passport-github@~1.1.0` to your project and require it in your `auth.js` as `GithubStrategy` like this: `const GitHubStrategy = require('passport-github').Strategy;`. Do not forget to require and configure `dotenv` to use your environment variables. </ins> To set up the GitHub strategy, you have to tell Passport to use an instantiated `GitHubStrategy`, which accepts 2 arguments: an object (containing `clientID`, `clientSecret`, and `callbackURL`) and a function to be called when a user is successfully authenticated, which will determine if the user is new and what fields to save initially in the user's database object. This is common across many strategies, but some may require more information as outlined in that specific strategy's GitHub README. For example, Google requires a *scope* as well which determines what kind of information your request is asking to be returned and asks the user to approve such access. The current strategy we are implementing has its usage outlined [here](https://github.com/jaredhanson/passport-github/), but we're going through it all right here on freeCodeCamp!

Discussion:
Advanced Node and Express section needs package versions to the instructions, as discussed in: Example: " Add <codepassport.socketio</codeversion <codeX.X.X</code, <codeconnect-mongo</codeversion <codeX.X.X</code, and <codecookie-parser</codeversion <codeX.X.X</codeas dependencies and require them as <codepassportSocketIo</code, <codeMongoStore</code, and <codecookieParser</coderespectfully. " Before this is undertaken: [x] Wait for to be merged [ ] Discuss which versions to use and how to convey this ( or )
I am leaning more toward the requirement, myself. With the carat prefix, will install the latest minor version. In theory, updates to the minor version are backwards compatible and shouldn't create any issues with the tests or challenges. However, minor versions can include depreciation notices like . The feature will still work, but this could be confusing to a camper. Using the tilde prefix means will install the latest patch version, which includes bug fixes but shouldn't lead to any depreciation notices. I think this will offer the best long-term compatibility with our tests and challenge instructions.
Well, it has happened: Last versions which definitely work: I have tested this. Now, discussion: 1) Just ask for to be installed 2) Also change the lesson/code to work with this latest version?
Hey how is this show stopper coming along?
Ah yes... I have updated the label, because it should have been removed by . Can a PR automatically remove an issue's label? Otherwise, this issue is still open and help wanted , as there are many packages which need their versioning fixed. If no one else, I can slot in some time for this tomorrow.
No rush. Thanks for confirming, I have removed the assignment since this is no longer a showstopper.
thank you so much for the Thank you for the suggestion. It helped me alot