Rename parsed type to Pep440Version.

Originally posted by @viceice in #115 (comment)

We probably need the equivalent functions as in https://github.com/renovateapp/renovate/blob/master/lib/util/semver.js

Options:

1. Machine translate an existing Python implementation of PEP440 and then add convenience wrappers
2. Port existing Python implementation "line by line" into JS manually
3. Write from scratch based on PEP440 specification

I think we want to avoid (3) due to the amount of work required.

Ansible uses a lot of four-part versions for example: https://pypi.org/project/ansible/#history

e.g. 2.3.1.0

Also GitHub's vulnerability alerts tend to use four-part versions for PIP, which makes it even more important.

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

Pending Approval

These branches will be created by Renovate only once you click their checkbox below.

• chore(deps): update linters (major) (eslint, eslint-plugin-jest)
• chore(deps): update pnpm to v9
• 🔐 Create all pending approval PRs at once 🔐

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• chore(deps): lock file maintenance

Pending Status Checks

These updates await pending status checks. To force their creation now, click the checkbox below.

• chore(deps): update pnpm to v8.15.8

Detected dependencies

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

What would you like to be able to do?

Remove these exportes, as they aren't easily usable via esm imports

Did you already have any implementation ideas?

Simply remove them. Probably breaking.

In the file lib/specifier.d.ts
The functions maxSatisfyingVesrion and minSatisfyingVersion, the parameter version have type string which needs to be of type string[] and renamed to versions.

What would you like to be able to do?

We should remove xregexp dependency, as there is no used benefit. We can maybe use RE2?

It looks like xregexp was added in old node v10 ages and is no longer required.

Did you already have any implementation ideas?

yes, simply use normal RegExp class.

/cc @RahulGautamSingh

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: undefined. Note: this is a nested preset so please contact the preset author if you are unable to fix it yourself.

What would you like to be able to do?

All declared functions in index.d.ts should be removed and replaced by the relevant exports from lib.

Did you already have any implementation ideas?
yes

/cc @RahulGautamSingh

Describe the bug

It appears that this implementation doesn't fully like pre-release versions.

WARN: pep440: failed to calculate newValue
{
  "result": "~=0.1.dev748+g3349dad",
  "newVersion": "0.1.dev748+g3349dad",
  "currentValue": "~=0.1.dev0"
}

Steps to reproduce

> satisfies("0.1.dev748+g3349dad", "~=0.1.dev748+g3349dad")
false
> satisfies("0.1.dev748+g3349dad", "==0.1.dev748+g3349dad")
true

What would you like to be able to do?

We use this package in renovate and due to absence of types.ts file we will have to create a .d.ts file there to declare the module as per typescript rules when strictNullCheck is true.
Image:-

Did you already have any implementation ideas?

We can add types.ts file here and declare the types in that file.

I have not written a types.ts file in past but I am learning TS and am interested in implementing the solution.

Migrate to GitHub Actions?

I noticed this repo has a travis.yml file, that's outdated (it uses Node 8).
Should we maybe migrate this to a GitHub Actions workflow and update the Node version?

Explain what this repo is about in readme?

This repository also doesn't explain in the README what the goal of this repo is, so anybody reaching this repo can't see if they need this or not.

Add badges for migrated GitHub Action?

Also it would be nice to have a badge for the tests on the README page, so that you can see at a glance if tests are passing/failing.

Add additional support to the inc function to increment versions using the release types premajor, preminor, prepatch, and prerelease.

These additional release types will mirror similar support in the node-semver package.

In semver, we have major/minor/patch and we also use "pin" (go from range to exact version). Default behaviour is to not treat patch differently so instead classify updates as major or minor. We don't use a special name for updates like 1.2.3-alpha.1 -> 1.2.3-alpha.2, these would end up being called "minor" or "patch".

In Docker we also have "digest" updates - updating the sha256 digest.

PEP440 prefers major.minor.micro where micro=patch. They also have additional parts, e.g. dev, post or pre releases.

Decision:

• force existing "patch" terminology on python? e.g. how we force PR even though GitLab uses MR
• support "micro" in configuration and alias it to patch?

Also:

• Need to explicitly support terminology for other update types? doesn't look like it

What would you like to be able to do?

We should use the node install action buildin cache like in other repos

Did you already have any implementation ideas?

Use same code as in other repo's

Export a function that takes two arguments; a version followed by a release type.

The version argument must be a valid PEP440 version, while the second argument, release type, must be one of major, minor, or patch.

This function will provide similar support to the node-semver package, but without support for pre-releases (as supported by node-semver), or other components of the PEP440 specification.

Support for pre-releases will be a follow-up enhancement.

I plan on implementing this in the following days.

Pre-existing Python package for version incrementing:

• https://pypi.org/project/bump/
• https://pypi.org/project/travis-bump-version/
• https://pypi.org/project/bump2version/
• https://pypi.org/project/version/
• https://pypi.org/project/mister-bump/

What would you like to be able to do?

Right now we need to manually format the code. This is a bad idea.

Did you already have any implementation ideas?

• Install Prettier as development dependency
• Include a prettier-fix command in the scripts in package.json
• Run a prettier lint command in the CI on pushes to main and incoming Pull Request

You can probably copy/paste/adjust the relevant Prettier scripts and CI setup from the main Renovate repository.