How to decide which version a newly crawled deprecation belongs to?

[BioPhoton]

• 0. start the crawler with --p tmp/deprecation.crawler.config.json -r 0 -nextVersion 1.3.6
-r or --releaseOrNum is a cli param that specifies
  • 💡 if no nextVersion is passed we crawl but keep them untagged
• from which version on we crawl (if the passed param is a string)
• from how many versions back from the last we crawl. 0 means all versions. (if the passed param is a number)
• 1. Crawl from latest tag received from -r
• 2. Add ruid, tag, date, remote to deprecation
• 3. Store crawled deprecations in json
• 4. Switching branches remain in a clean git history
  • 💡 Optionally crawl only the diff from 2 tags so we don't recrawl already crawled deprecations
  • 💡💡 Optionally crawl only the files passing a filePathFilter function. (monorepo)
    conventional-changelog-cli has 2 interesting params: --commit-path and --tagPrefix. Both very useful for monorepo setups. commitPath filters for files based on a glob pattern e.g. **/libs/my-lib and tagPrefix serves a filter for tag names e. g. my-lib@.

[N]. checkout next tag
moving through branches in the right order is excluded for now.

• 10. Sync Repo. As we have all information in a deprecation we can simply create the link and update the repository on e.g. main branch.
• 11. As we have all deprecations in a git ignored folder we have to move them in the right place as from now on we only crawl newly added deprecations.
• 12. Another process has to tag the current version in the code.

[BioPhoton]

I added all infos we know so far in #67

Also #61 is implementing a "tag semver filter" to filter relevant tags out.

A deprecation in suspense (in master but not released) is also mentioned there.

To answer in short, a deprecation lives in between 2 semver releases tags. And suspending ones are unversioned.

Question here, how to make sure deprecations don't get lost in suspense state?

[BioPhoton]

Question here, how to make sure deprecations don't get lost in suspense state?

Answer: we have to specify the next version manually. The next version is mostly determined somewhere else. (another tool like conventional-recommended-bump or human input)

[timdeschryver]

I will probably work on a minimal implementation later:

• asks for which versions to crawl / or asking a starting version and crawl until the present. The latter is a bit more complicated because lower versions could also be released in between, e.g. 6.0.0; 6.1.0; 5.6.1; 6.1.1. Here I would expect the 5.6.1 is ignored.
• ask for tsconfig input after checkout, and before the crawling process. To ensure we always crawl the correct files. This is also the reason of asking for versions in step 1, if we crawl all versions, this step will be tedious. (I wonder if we could build up the tsconfig for one run and remove it afterwards)
• crawling a version
• repeat
• remove duplicate deprecations (based on the ruid)
• commit

Note that groups are not included because we have a separate command for it, I wanted to keep this history command as simple as possible (for now). We also won't update the existing codebase because it doesn't add any value? For it to have any value a new version should be released.

[BioPhoton]

asks for which versions to crawl / or asking a starting version and crawl until the present. The latter is a bit more complicated because lower versions could also be released in between, e.g. 6.0.0; 6.1.0; 5.6.1; 6.1.1. Here I would expect the 5.6.1 is ignored.

This should fix the problem: https://github.com/timdeschryver/deprecation-manager/blob/master/packages/deprecation-crawler/src/lib/tasks/ensure-git-tag.ts#L126

ask for tsconfig input after checkout, and before the crawling process. To ensure we always crawl the correct files. This is also the reason of asking for versions in step 1, if we crawl all versions, this step will be tedious. (I wonder if we could build up the tsconfig for one run and remove it afterwards)

IMHO we have this check for tsConfig already in the process: https://github.com/timdeschryver/deprecation-manager/blob/master/packages/deprecation-crawler/src/lib/tasks/ensure-tsconfig-path.ts#L68

commit

I would not put too much effort in the commit step. With gitActions we can use the one package I tried in the actions poc.
And for local work, we may anyway want to commit yourself?

Note that groups are not included because we have a separate command for it, I wanted to keep this history command as simple as possible (for now).

Agree! It as also easier to work with if we do it later...

We also won't update the existing codebase because it doesn't add any value? For it to have any value a new version should be released.

Agree!

[timdeschryver]

Thanks for pointing me towards the semver sort!

IMHO we have this check for tsConfig already in the process

The reason why I want to ask for a tsconfig file every time, is because the tsconfig file might be modified in between versions. I'm worried that the tsconfig doesn't include the correct source files (because a newer new tsconfig file is used to build the project).

[BioPhoton]

The reason why I want to ask for a tsconfig file every time, is because the tsconfig file might be modified in between versions. I'm worried that the tsconfig doesn't include the correct source files (because a newer new tsconfig file is used to build the project).

Now I got it! Sure let's do that! But with the default option as the previous tsConfig path to easily hit enter to continue

[timdeschryver]

It bothered me to select a tsconfig, so I wanted to try something else. See #101 for more info 😁 and let me know what you think.