Description

Per the discussion in #52, we have decided to move from Flow types to TypeScript to follow industry best practices.

What's the benefit of this feature?

1. Moves us in line with current industry standards in Open Source repositories. Flow usage is waning as TS usage is waxing
2. Better integration with text editors than Flow
   • this repo works in large part with objects, and having enhanced editor support for working with those objects (auto-filling properties for example) is a win
3. Helps auto-document code
4. Many other TS benefits...

Possible Implementation (optional)

This can happen in a few parts. Here are the general broad strokes:

• rename .js files to .ts
• uninstall flow-bin
• install typescript as a dev dep and initialize typescript
• convert flow types to typescript types (consider looking at our definitelytyped entry for inspiration)
  - Could also try using this conversion project
• Add TS documentation to the readme and any convenience scripts to the package json
• stretch goal: add TS checking to our CI

Description

A significant portion of maintenance effort of this repo is updating dependencies. After a quick search, we recently found that we had an unused dependency (#33). We should vet our other dependnencies to make sure they are currently used, and their use is unique enough that it warrants an external library.

What's the benefit of this feature?

The less external deps we have, the less overall maintenance will be required to keep git-parse up to date. Also, less external dependencies can help make a library more durable (less moving parts)

Acceptance Criteria

1. Look at each current dependency and note it's usage.
   • If a dependency has no usages, create a ticket to remove it
   • If a dependency has a usage that could be easily internalized (think: https://www.npmjs.com/package/is-odd), make a ticket to replace it with an internal utility

Description

Add a contributing guide and scrub the current readme and code of conduct to ensure it aligns with the Wayfair OSPO best practices guides here

What's the benefit of this feature?

Best OS practices dictate a strong contributor guide. In addition, our other documentation hasn't been scrubbed for quality/detail since it was written.

Acceptance Criteria

1. Repo has a contributor guide added
2. Readme and Code of Conduct align with the OSPO best practices

Description

Add the Stale action workflow to close issues open for more than 60 days

What's the benefit of this feature?

The natural state of the world is entropy. This will help ensure our repo issues are fresh and relevant.

Possible Implementation (optional)

See https://github.com/marketplace/actions/close-stale-issues for adding to this repo. Also note https://github.com/wayfair-incubator/oss-template/blob/main/.github/workflows/stale.yml

❗ Disclaimer - this is meant to illicit some conversation. Please weigh in with your thoughts!

Question

This repository uses Flow types to type check javascript. While Flow is a perfectly fine type checking system, there are some drawbacks. First, flow-bin is losing steam and Typrescript continues to gain widespread support.

While this isn't inherently a bad thing, I think we should consider how it may impact the ease-to-contribution for our repo here.

Also, Flow doesn't have a clear and public roadmap (note, we still haven't seen a v1). For comparisons sake, Typescript does have a clear roadmap and a stable v1

Context

Given the focused nature of this package, I'm of the mind we should keep it as simple and easy to contribute to as possible. I don't personally see the benefit of Flow for avoiding type-related bugs and it could deter future contributor-ship given it's lack of widespread adoption.

Comments

I think we should remove flow. If someone has a strong opinion on type checking, we could convert to TS. Looking for thoughts!

Question

Manually upgrading the package.json version and adding a changelog entry are possible automation / validation targets. One example of this would be semantic commits powering automatic changelog updates and a required version bump / changelog check for PRs to be merged. Does anyone have strong thoughts / opinions on if we should do this and if so, what it would look like?

Context

We recently had a PR that made a major version change and didn't include a package json update, and also had a pr that didn't include a changelog update. These seem like good DX opportunities to automate away the need to think about this and in doing so, potentially increase the quality of the repo.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Datasource	Name	Replacement PR?
npm	@babel/plugin-proposal-class-properties
npm	@babel/plugin-proposal-object-rest-spread

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update babel monorepo (@babel/cli, @babel/core, @babel/plugin-proposal-object-rest-spread, @babel/preset-env, @babel/preset-typescript)
• chore(deps): update dependency eslint to v8.57.0
• chore(deps): update yarn to v3.8.2
• chore(deps): update dependency eslint to v9
• chore(deps): update js-devtools/npm-publish action to v3
• chore(deps): update wagoid/commitlint-github-action action to v6
• chore(deps): update yarn to v4
• Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• chore(deps): update dependency @types/byline to v4.2.36
• chore(deps): update dependency @types/util.promisify to v1.0.8
• chore(deps): update dependency husky to v8.0.3
• chore(deps): update dependency minimist to v1.2.8
• fix(deps): update dependency util.promisify to v1.1.2
• chore(deps): update commitlint monorepo to v17.8.1 (@commitlint/cli, @commitlint/config-conventional)
• chore(deps): update dependency prettier to v2.8.8
• chore(deps): update dependency typescript to v4.9.5
• chore(deps): update jest monorepo to v29.5.12 (@types/jest, jest)
• chore(deps): update typescript-eslint monorepo to v5.62.0 (@typescript-eslint/eslint-plugin, @typescript-eslint/parser)
• chore(deps): update actions/checkout action to v4
• chore(deps): update actions/setup-node action to v4
• chore(deps): update actions/stale action to v9
• chore(deps): update commitlint monorepo to v19 (major) (@commitlint/cli, @commitlint/config-conventional)
• chore(deps): update dependency husky to v9
• chore(deps): update dependency prettier to v3
• chore(deps): update dependency typescript to v5
• chore(deps): update typescript-eslint monorepo to v7 (major) (@typescript-eslint/eslint-plugin, @typescript-eslint/parser)

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Description

This repo currently has no documentation on how often we plan on releasing the library, or how to do so. We currently plan on releasing at least once a quarter, but more if necessary.

Acceptance Criteria

• Release scheduling documentation has been added to the README
• Instructions to release have been added to the contributing guide, which reference the required Changelog updates

Description

We should specify an .npmrc for this repo that resolves packages to the public npm package registry, instead of any company-specific registry that Wayfairians would have configured on their machines

What's the benefit of this feature?

avoid committing any company-specific endpoints in a package.lock

Possible Implementation (optional)

write .npmrc that points to public registry.

Description

Add a "No Response" workflow to ensure our issues remain fresh and relevant to the project

What's the benefit of this feature?

We always believe our contributors will provide detailed bug / feature reports with enough information to be actionable. Let's automate the process of ensuring that continues to happen!

With a No Response workflow, If you tag an issue more-information-needed and the issue reporter doesn’t follow up within a specified period of time, No Response will automatically close the issue out.

Possible Implementation (optional)

1. Add a more-information-needed label
2. Follow the https://github.com/lee-dohm/no-response repo to add a workflow for closing no response issues

Description

This repo & library are missing a Changelog to document the changes in each version.

Acceptance Criteria

• Add a changelog, based on Keep a Changelog
• Add note to contributing & release guides for updating said changelog
• Add note in changelog for anything pre 1.0.5 we do not have the details

What happens?

If the file name contains spaces, the value of filesAdded.path is not expected.It only shows part of file name.

What were you expecting to happen?

If I have file a b.md,filesAdded.path should be a b.md,not a

Reproducing the Bug

First,init a new git repo:

git init

then,create a new file t t.mdand run git add:

git add "t t.md" 

then commit:

git commit -m 1

then run JS file:

const { gitToJs } = require('git-parse');

const commitsPromise = gitToJs(process.cwd());

commitsPromise.then((commits) => console.log(JSON.stringify(commits, null, 2)));

I got :

[                                                                   
  {                                                                 
    "hash": "afb09d58e3bf0b99789ef9a368f4e9c4e80ef479",             
    "authorName": "shadowfish07",                                   
    "authorEmail": "[email protected]",
    "date": "Fri, 6 May 2022 21:18:34 +0800",                       
    "message": "1",                                                 
    "filesAdded": [                                                 
      {                                                             
        "path": "t"                                                 
      }
    ],
    "filesDeleted": [],
    "filesModified": [],
    "filesRenamed": []
  }
]

Environment

Windows 10

Hey, could you please release a new version for the actual babel-polyfill / core-js 2 drop? :) Thanks

Description

During the Jest upgrade, I noticed gitLogStream method has an api that returns an object of stream, addErrorHandler, and does not easily allow for mocking out the actual git command executions.

I'd like to explore if we can update this module in a few ways:

• Return a promise, to chain .then() and .catch() handlers
• Move the git command execution to a "git api" module which can be mocked out in specs

This would be a breaking change to the public api, so anyone who picks this up should be aware not to merge until we're ready to cut a new major version as we will likely want to combine this with other breaking changes.

What's the benefit of this feature?

• Improved testability (is that a word?)
• Simpler API for consumers (no custom methods like .addErrorHandler(), can simply use .catch())

Testing Requirements

Per #32 (comment), be sure to test this functionality on a large repo (think Apollo or something of similar size) and ensure there are no performance / memory degradations

Question

How do we feel about continuing to use npm as the package manager here?

Context

One of my favorite features of yarn includes running yarn why to tell us why a certain dependency is being pulled in. This can be super useful when tracking down vulnerabilities (and is what I used to find the root of the problem for the jest upgrade ).

Related issues

None

Comments

This is a minor dev experience change and is my personal preference, interested in how the other maintainers feel about this.

Description

Issue and PR templates help standardize and encourage contributions. Let's add both.

Github docs on issue and pr templates

Handy dandy templates repo

Acceptance Criteria

1. Create at least the following issue templates
   • bug
   • feature
   • discussion
2. Create a PR template

Description

Should we provide a cleaner/smaller release file?

What's the benefit of this feature?

Reduce size of release. Don't send files that aren't used by the npm package itself.

Possible Implementation (optional)

Seems like there are actions available to help with this if we don't want to do it ourselves.
Example (not endorsing, just providing as example)
https://github.com/shashkovdanil/clean-publish

Description

This repo is missing automation to verify / validate suggested changes.

To help folks contribute to the repo, and increase our confidence in reviewing PRs, checks should be automated and reported on PRs.

Acceptance Criteria

• GitHub checks/actions run on PRs
• Checks include:
  • Running jest tests
  • Running lints
  • Validating formatting (check prettier run)
• Checks are added as a branch protection rule (i.e. block merging to main if failed)

Description

Better verbosity and logging for output of npm install / npm ci in our PR checks

What's the benefit of this feature?

Investigation of any issues or possible improvements to be made to npm install are nearly impossible with the current verbosity -- we missed an important issue on that output, we would like to not do that again.

Possible Implementation (optional)

Description

As mentioned in #38, it looks like nock is an unused dependency. Furthermore, we don't want to encourage it's usage by having it available as we prefer mock service modules vs use nock.

What's the benefit of this feature?

Removes another dependency that is unnecessary, resulting in less overall maintenance over time.

Possible Implementation (optional)

1. npm uninstall nock
2. Check that everything works 👍

Description

Add Contributing file.

Can use or base it off of the oss-template file:
https://github.com/wayfair-incubator/oss-template/blob/main/CONTRIBUTING.md

What's the benefit of this feature?

Helps get the repo closer to in sync with the oss-template and improve the repos community metrics score.

Description

I'd like to use OSSF's scorecards for git-parse to give an idea outwardly of our vulnerabilities, and how we do in keeping up the project over time.

We can set this up in a bespoke part of the GitHub scanning suite, see link provided for details.

What's the benefit of this feature?

Widely available and adopted scoring of our project in how it's security vulnerabilities are addressed will make this project more attractive and reliable for our downstream consumers.

Possible Implementation (optional)

Installation instructions here, happy to do it myself if nobody picks this up, or should be an easy contribution!

Description

The node version specified in the README is overly permissive and allows for an unsupported version of node, node 8.

Suggested Fix

• Test package when using node LTS (14.x)
• Add engines config to alert users of change
• Update README to reflect change

Description

Remove the lodash dev-dependency

What's the benefit of this feature?

Lodash is not used in this repo, however we have it as a dev dependency. This will cause non-zero dependabot inbounds to upgrade versions in the future which is a waste of time if the library is unused.

Possible Implementation (optional)

yarn remove lodash

Open Question (Edit: Answered in the comments below)

If we remove a dev dep that is unused, what would be the proper semver change there? @finn-orsini I'd love your thoughts here.

Description

Repo does not contain a Prettier configuration. This can lead to formatting inconsistencies.

Suggested Fix

• Add a prettier config & prettier ignore. Can use the defaults for now.
• Run prettier on all files

Snyk warns about the following security vulnerability: https://app.snyk.io/vuln/SNYK-JS-GITPARSE-1290380.
You up for a fix? :)

What happens?

In case of a PR renaming a file with spaces in the path, the old and new path of the change entry will be broken. Maybe similar to #63

What were you expecting to happen?

Should recognize them correctly

Reproducing the Bug

Check out https://github.com/vuejs/docs
Try to parse commit bb9f97a9ca0acc7408e0c59750e712d94360f499

The diff via git show in the terminal:

diff --git a/src/.vuepress/public/images/sponsors/primevue copy.png b/src/public/images/sponsors/primevue copy.png
similarity index 100%
rename from src/.vuepress/public/images/sponsors/primevue copy.png
rename to src/public/images/sponsors/primevue copy.png

The diff entry via git-parse:

{
      "oldPath": "src/.vuepress/public/images/sponsors/primevue copy.png\tsrc/public/images/sponsors/primevue",
      "newPath": "copy.png"
    }

Environment

3.0.0 on MacOs