We have several dependencies that in the latest major version have been migrated to ES modules. That means that most likely the CJS versions will no longer be maintained. To avoid depending on stale packages, we should research what's the best way forward. Here are some options:
- not do anything. As long as there are no issues with the dependencies that we use, there's no reason for us to worry about upgrading to newer versions. It does mean that we need to pay more attention to future versions and track if there's nothing that would require us to take some action after all
- find alternative packages that are available as CJS. This would likely mean refactoring our code that depends on those packages. If ESM is the way to go, we might end up in the same situation after all
- migrate CLI to use ESM instead of CJS. Upgrade packages to the latest ESM versions. What about dependencies that are CJS: can we keep using them or do we need to find ESM alternatives for them?
If we choose to change our package format, let's keep in mind that we expose a public API and which ideally should stay backwards compatible.
Are there any other options that you see and which we should consider @pnp/cli-for-microsoft-365-maintainers? If not, the next step would be to research the viability of these options and their trade-offs.
We have several dependencies that in the latest major version have been migrated to ES modules. That means that most likely the CJS versions will no longer be maintained. To avoid depending on stale packages, we should research what's the best way forward. Here are some options:
If we choose to change our package format, let's keep in mind that we expose a public API and which ideally should stay backwards compatible.
Are there any other options that you see and which we should consider @pnp/cli-for-microsoft-365-maintainers? If not, the next step would be to research the viability of these options and their trade-offs.