Add bun package manager

[markhallen]

What are you trying to accomplish?

As a first step towards adding support for Bun we are adding the BunPackageManager class and extracting package managers into their own files.

• This is the first part of merging the changes suggested in Support Bun with bun.lock #11209 in digestible PRs.
• Contributes to add support for bun #6528

Anything you want to highlight for special attention from reviewers?

For wider context you can check #11209 or #11248

The ultimate plan is to use a new structure for multiple Javascript ecosystems similar to #1862.

This PR was put together before the change in approach. It was decided that we proceed with these PR's as-is.

We will then follow-up with a PR migrating to the new structure. This migration PR will then serve as an example for the migration of the other Javascript ecosystems.

How will you know you've accomplished your goal?

The old specs should pass after the file structure changes and the new specs should pass for the new package manager.

Checklist

• I have run the complete test suite to ensure all tests and linters pass.
• I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
• I have written clear and descriptive commit messages.
• I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
• I have ensured that the code is well-documented and easy to understand.

[amazimbe]

Hey @markhallen I know you were not there yesterday but we discussed and agreed that bun will be implemented as it's own ecosystem independent of npm & yarn.

[kbukum1]

Hi @markhallen,

I noticed some differences in the structures of your Bun PRs. I thought it might follow a structure similar to the one used in the Docker Compose PR.

For example, it could look like this if we follow the same approach:

  - lib/dependabot
    - common (or shared)
    - npm_and_yarn
        - file_fetcher
           ...
        - file_parser
          ....
       - file_updater
         ...
       - file_fetcher.rb
       - file_parser.rb
       - file_updater.rb
       ... so on
    - npm_and_yarn.rb
    - bun
         - file_fetcher
           ...
        - file_parser
          ....
       - file_updater
         ...
       - file_fetcher.rb
       - file_parser.rb
       - file_updater.rb
       ... so on
    - bun.rb```

If you follow this structure, you won’t need to make any changes to npm_and_yarn. Later, when we separate other package managers, we can adopt the same structure to create individual npm, pnpm, and yarn folders. This will allow us to treat them as distinct ecosystems while retaining npm_and_yarn for compatibility and managing deprecation/unsupported lifecycles.

[markhallen]

Hi @markhallen,

I noticed some differences in the structures of your Bun PRs. I thought it might follow a structure similar to the one used in the Docker Compose PR.

For example, it could look like this if we follow the same approach:

  - lib/dependabot
    - common (or shared)
    - npm_and_yarn
        - file_fetcher
           ...
        - file_parser
          ....
       - file_updater
         ...
       - file_fetcher.rb
       - file_parser.rb
       - file_updater.rb
       ... so on
    - npm_and_yarn.rb
    - bun
         - file_fetcher
           ...
        - file_parser
          ....
       - file_updater
         ...
       - file_fetcher.rb
       - file_parser.rb
       - file_updater.rb
       ... so on
    - bun.rb```

If you follow this structure, you won’t need to make any changes to npm_and_yarn. Later, when we separate other package managers, we can adopt the same structure to create individual npm, pnpm, and yarn folders. This will allow us to treat them as distinct ecosystems while retaining npm_and_yarn for compatibility and managing deprecation/unsupported lifecycles.

Thanks @kbukum1

As discussed on Friday. This PR was put together before the change in approach. It was decided in the Friday standup that we proceed with these PR's as-is. We will then follow-up with a PR migrating to the new structure which will have the structure you have outlined above. This PR will then serve as an example for the migration of the other Javascript ecosystems.

Thanks @kbukum1

The plan is to use the structure you have defined, but in a later PR.
As discussed on Friday. This PR was put together before the change in approach. It was decided in the Friday standup that we proceed with these PR's as-is. We will then follow-up with a PR migrating to the new structure which will have the structure you have outlined above. This PR will then serve as an example for the migration of the other Javascript ecosystems.