You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the course of #1038, we discovered that we actually can have a peer-dependency-like situation between the commonjs plugin and the node-resolve plugin: If the new commonjs version is used together with a node-resolve version older than 13.0.6, then we would like to throw an error.
Unfortunately while it is easy to discover that the node-resolve plugin is used by inspecting build options, it is close to impossible to discover its actual version.
This PR does something very simple: It fetches the plugin version from the package.json file and attaches it as a version property to the plugin so that other plugins can inspect it.
This could serve as a pattern for other plugins as well. E.g. I am also attaching a version property to the commonjs plugin in #1038.
To ease the release of #1038, I would see having something like this in node-resolve as blocking for the release of #1038. If we want to recommend this pattern to others, I am also considering to include a recommendation in the "plugin communication" section of the official Rollup docs.
Checking the version with the newly released plugin it turns out that the published version is always one release behind. E.g. @rollup/plugin-node-resolve@13.1.0 reports to have version 13.0.6 and 13.1.1. is reported as 13.1.0. The reason is that the last build of the plugin occurs before the version is incremented.
@shellscape the easiest possible way to address this is to add a "prebublish": "pnpm build" script to the node-resolve package.json file. This script would indeed run after the version is increased. Do you see any issues with that? Then I would create a small PR.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rollup Plugin Name:
node-resolveThis PR contains:
Are tests included?
Breaking Changes?
If yes, then include "BREAKING CHANGES:" in the first commit message body, followed by a description of what is breaking.
List any relevant issue numbers:
#1038
Description
In the course of #1038, we discovered that we actually can have a peer-dependency-like situation between the commonjs plugin and the node-resolve plugin: If the new commonjs version is used together with a node-resolve version older than 13.0.6, then we would like to throw an error.
Unfortunately while it is easy to discover that the node-resolve plugin is used by inspecting build options, it is close to impossible to discover its actual version.
This PR does something very simple: It fetches the plugin version from the package.json file and attaches it as a
versionproperty to the plugin so that other plugins can inspect it.This could serve as a pattern for other plugins as well. E.g. I am also attaching a version property to the commonjs plugin in #1038.
To ease the release of #1038, I would see having something like this in node-resolve as blocking for the release of #1038. If we want to recommend this pattern to others, I am also considering to include a recommendation in the "plugin communication" section of the official Rollup docs.