PokerGuy

const push = async (file, fileName) => {
    const client = new aws.SecretsManager();
    const spURL = `https://<your site>.sharepoint.com/sites/<your specific subsite>/_api/web/GetFolderByServerRelativeUrl('Documents')/Files/Add(url='${fileName}', overwrite=true)`;
    try {
        const data = await client.getSecretValue({ SecretId: '<whatever you called your secret>' }).promise();
        const secret = JSON.parse(data.SecretString).<whatever you called your secret>;
        const getToken = await axios.post('https://accounts.accesscontrol.windows.net/<sharepoint resource id>/tokens/OAuth/2',
            querystring.stringify({
                grant_type: 'client_credentials',
                client_id: '<ask your sharepoint person for this it's a something@tenant id>',

nzakas

Versioning in a Repository

Lately I've been doing a lot of thinking around versioning in repositories. For all the convenience and ubiquity of package.json, it does sometimes misrepresent the code that is contained within a repository. For example, suppose I start out my project at v0.1.0 and that's what's in my package.json file in my master branch. Then someone submits a pull request that I merge in - the version number hasn't changed even though the repository now no longer represents v0.1.0. The repository is actually now in an intermediate state, in between v0.1.0 and the next official release.

To deal with that, I started changing the package.json version only long enough to push a new release, and then I would change it to a dev version representing the next scheduled release (such as v0.2.0-dev). That solved the problem of misrepresenting the version number of the repository (provided people realize "dev" means "in flux day to day"). However, it introduced a yucky workflow that I really hate