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
When we have a need to introduce a new API, e.g. see #16027, we also unfortunately tend to break support/introduce some churn for older versions of Gatsby in the process.
For example, given the above API validatePluginOptions -- if we added that API to a plugin, and that plugin was updated but the gatsby version was kept constant (very common!) the following error would appear:
The plugin "gatsby-source-contentful@2.1.5" is exporting a variable named "validatePluginOptions" which isn't an API.
This is a straw man (aka a proposal that potentially has flaws, and that I'd love to iterate to something better) proposal.
We create (at build/publish time) a list of known APIs in api-node-docs.js as JSON (e.g. gatsby/node-apis.json, gatsby/browser-apis.json, etc. or perhaps one big api.json file with keys for node, browser, etc.)
We'll probably want to use Babel or something to extract all the exports
Ideally, would also include the version introduced and then some metadata as to whether it should be "breaking" to older versions or not (e.g. some are crucial for functionality, others can/should be a noop as they're an enhancement, not crucial)
We build into bootstrap a request to these files (with Unpkg or equivalent), to know about the latest APIs
If a breaking API, break with a message like the below
The plugin {PLUGIN_NAME}@{PLUGIN_VERSION} is trying to use the API: {API_NAME} which is not available in gatsby@{GATSBY_VERSION}
To fix, upgrade to gatsby@{GATSBY_API_VERSION} with:
npm install gatsby@^{GATSBY_API_VERSION}
Note: if the network call fails, we need to fail quickly, and then tweak the message to be less useful and probably presumed breaking.
Motivation
We need to introduce new APIs. We can't break people's builds when they (very likely!) upgrade plugin versions, while keeping Gatsby versions constant.
We should encourage to upgrade, but not break builds whenever possible. We want to continue to iterate and build in useful functionality, but we also don't want to cultivate an environment of churn and frustration.
The text was updated successfully, but these errors were encountered:
We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contributefor more information about opening PRs, triaging issues, and contributing!
Thanks for being a part of the Gatsby community! 💪💜
gatsbotbot
added
the
stale?
Issue that may be closed soon due to the original author not responding any more.
label
Aug 14, 2019
It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.
Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!
Thanks again for being part of the Gatsby community!
Summary
When we have a need to introduce a new API, e.g. see #16027, we also unfortunately tend to break support/introduce some churn for older versions of Gatsby in the process.
For example, given the above API
validatePluginOptions
-- if we added that API to a plugin, and that plugin was updated but the gatsby version was kept constant (very common!) the following error would appear:See #15680 for a real world example of the issue.
Basic example
This is a straw man (aka a proposal that potentially has flaws, and that I'd love to iterate to something better) proposal.
The structure could look something like this:
Breaking Message
Note: if the network call fails, we need to fail quickly, and then tweak the message to be less useful and probably presumed breaking.
Motivation
We need to introduce new APIs. We can't break people's builds when they (very likely!) upgrade plugin versions, while keeping Gatsby versions constant.
We should encourage to upgrade, but not break builds whenever possible. We want to continue to iterate and build in useful functionality, but we also don't want to cultivate an environment of churn and frustration.
The text was updated successfully, but these errors were encountered: