Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation: providers.mdx text not matching snippets #2575

Closed
ansgarm opened this issue Feb 2, 2023 · 1 comment 路 Fixed by #3359
Closed

Documentation: providers.mdx text not matching snippets #2575

ansgarm opened this issue Feb 2, 2023 · 1 comment 路 Fixed by #3359
Assignees
Labels
documentation Improvements or additions to documentation enhancement New feature or request priority/important-soon High priority, to be worked on as part of our current release or the following one.
Milestone

Comments

@ansgarm
Copy link
Member

ansgarm commented Feb 2, 2023

Community Note

  • Please vote on this issue by adding a 馃憤 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

The text states:

The following example imports the DnsimpleProvider and Record resources from ./.gen/providers/dnsimple

(source)

But the following TypeScript snippet imports from "@cdktf/provider-dnsimple/lib/provider" and the other languages import from their respective locally built bindings (which have a different path than stated in the sentence quoted above).

References

@ansgarm ansgarm added documentation Improvements or additions to documentation enhancement New feature or request labels Feb 2, 2023
@xiehan xiehan added the priority/important-soon High priority, to be worked on as part of our current release or the following one. label Feb 15, 2023
@xiehan xiehan added this to the 0.20 milestone Dec 12, 2023
DanielMSchmidt pushed a commit to cdktf/cdktf-provider-project that referenced this issue Dec 15, 2023
While this is not technically a breaking change, I want to force this to
be released as v0.5.0 so that it's easier to roll back to v0.4.x in case
there are any issues with this in testing.

At its core, this change is relatively simple: it introduces an
`isDeprecated` flag on the config for providers built using this project
that defaults to falsy. All the new behavior is controlled by that flag,
so it _should_ mean that this is safe to merge, as no new functionality
will be triggered for any providers unless/until they are marked as
deprecated.

(There technically is also a new option called `deprecationDate` -- in
practice I don't intend to use that and will just rely on the build
date; however, in order to not have the test snapshots be regenerated
every day with a new date, I needed a way to force-override the `new
Date()` behavior.)

If the `isDeprecated` flag is set to `true`, then the following happens:
- The "should-release" logic is removed because we want to force one
final release
- The "provider upgrade" and "upgrade-main" workflows are removed to
avoid any accidental updates before the repo is archived
- The text in the README will have a disclaimer about the deprecated
status of this package added to it, and the sections about Versioning
and Contributing that are no longer relevant will be removed
- Thanks to #371, these README changes will show up in the Go repository
as well
- The Go package will be marked as deprecated -- see
[here](golang/go#40357) for how this is done
in Go
- The NPM package will be [marked as
deprecated](https://docs.npmjs.com/deprecating-and-undeprecating-packages-or-package-versions/)
after the next and final release

PyPi and Maven unfortunately don't support deprecating an entire
package. NuGet does, but there's no API/CLI for it; it has to be done
via the web UI.

While it's huge, looking at the test snapshot file might be the best way
to visualize the changes. The first example in that file is of a
provider that's been marked as deprecated -- in particular, scrolling
down to the README will demonstrate what that looks like for a
deprecated provider. The other snapshots demonstrate that there
shouldn't be any unintentional outcomes for providers that have not been
explicitly marked as deprecated.

Side note: while I was working on this I realized that
hashicorp/terraform-cdk#2575 is very important now because we link to
https://cdk.tf/imports a lot to explain how to manually generate
bindings, but some of the examples there incorrectly use the prebuilt
providers, so I have added that issue to our next release.

---------

Signed-off-by: team-tf-cdk <github-team-tf-cdk@hashicorp.com>
Co-authored-by: team-tf-cdk <github-team-tf-cdk@hashicorp.com>
Maed223 added a commit that referenced this issue Jan 5, 2024
### Related issue

Fixes #2575

### Description

Typescript example in `providers.mdx` now uses locally build bindings in
it's imports to align with documentation wording.
Copy link
Contributor

github-actions bot commented Feb 5, 2024

I'm going to lock this issue because it has been closed for 30 days. This helps our maintainers find and focus on the active issues. If you've found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 5, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
documentation Improvements or additions to documentation enhancement New feature or request priority/important-soon High priority, to be worked on as part of our current release or the following one.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants