pulumi

History

Sean Holung bf251932ef Fix enum rendering issue (#15415 ) Fixes: https://github.com/pulumi/registry/issues/3724 Fixes: https://github.com/pulumi/registry/issues/2966 This PR is to resolve the enum rendering issue. The enums were not being rendered on the page at all due to a misconfigured language choosable (i.e. `<pulumi-choosable>`) that wraps the enum section. I found out this had to do with the lang property being set as `nodejs` when instead the choosable expects `javascript` or `typescript` as the valid values. I then followed the pattern of what we seem to be doing for the other pulumi-choosables which have this issue, which is to have an if statement that sets it to `javascript,typescript` if `nodejs` is given. This is how the rendering looks now. I have not adjusted any layouts of the template or anything along those lines, only fixed the choosable. I am wondering if this is actually what was intended for these, as we have a display name in the left column that is ~useless IMO and the right column has the value. I am assuming this was done to match the formatting of the other nested types that are displayed since these enums are treated as such. Though I don't think it is optimal for what we are trying to present given that we do not have descriptions for any of the individual enum values and what they represent. Should we consider doing something like having a separate enum section that is more purpose built for the data we can display where we just have the enum type in the left column, followed by the valid enum values in the right column. For example: \| Instance Type \| a1.2xlarge, a1.4xlarge , a1.large.... \| Should we consider moving to something like this or continue following the current pattern we have? Thoughts welcome! Also, we can consider shipping this as it is as it is still an improvement over what we have now and file a follow up issue to re-assess the way this is presented. This is the current render that this PR fix will produce: <img width="795" alt="Screen Shot 2024-02-09 at 8 35 21 AM" src="https://github.com/pulumi/pulumi/assets/16751381/352462b7-720c-4495-bdfe-f62cfdd946c0">	2024-02-12 21:25:36 +00:00
..
test	Fix enum rendering issue (#15415 )	2024-02-12 21:25:36 +00:00
utils	[schema] Fixes marshalling the "plain" flag from object or resource properties (#14648 )	2023-11-27 11:05:03 +00:00

Sean Holung bf251932ef

Fixes: https://github.com/pulumi/registry/issues/3724
Fixes: https://github.com/pulumi/registry/issues/2966

This PR is to resolve the enum rendering issue. The enums were not being
rendered on the page at all due to a misconfigured language choosable
(i.e. `<pulumi-choosable>`) that wraps the enum section. I found out
this had to do with the lang property being set as `nodejs` when instead
the choosable expects `javascript` or `typescript` as the valid values.
I then followed the pattern of what we seem to be doing for the other
pulumi-choosables which have this issue, which is to have an if
statement that sets it to `javascript,typescript` if `nodejs` is given.

This is how the rendering looks now. I have not adjusted any layouts of
the template or anything along those lines, only fixed the choosable. I
am wondering if this is actually what was intended for these, as we have
a display name in the left column that is ~useless IMO and the right
column has the value. I am assuming this was done to match the
formatting of the other nested types that are displayed since these
enums are treated as such. Though I don't think it is optimal for what
we are trying to present given that we do not have descriptions for any
of the individual enum values and what they represent.

Should we consider doing something like having a separate enum section
that is more purpose built for the data we can display where we just
have the enum type in the left column, followed by the valid enum values
in the right column. For example:

| Instance Type | a1.2xlarge, a1.4xlarge , a1.large.... |

Should we consider moving to something like this or continue following
the current pattern we have? Thoughts welcome!

Also, we can consider shipping this as it is as it is still an
improvement over what we have now and file a follow up issue to
re-assess the way this is presented.

This is the current render that this PR fix will produce:

2024-02-12 21:25:36 +00:00

test

Fix enum rendering issue (#15415 )

2024-02-12 21:25:36 +00:00

utils

[schema] Fixes marshalling the "plain" flag from object or resource properties (#14648 )

2023-11-27 11:05:03 +00:00