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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(js-api): add types for Editor Config Contributor client extension #1185

Merged
merged 2 commits into from
Dec 20, 2023

Conversation

markocikos
Copy link
Member

References

What is the goal of this PR?

Adding public types for Editor Config Contributor client extension.

Notes:

  • I intentionally named this in a generic way, EditorConfigTransformer and not EditorConfigContributor. We plan to add a different CET in the future, that will not use the Java EditorConfigContributor framework in DXP. That CET will still be able to use this API, as both will do the same config transformation in the end.
  • I don't think we want to manage anything more specific than [key: string]: any; for config structure. This is based on the third-party APIs and is likely to change with time. Being so generic will also enable us to be consistent with APIs for CKEditor 5 or other editors. I added in commited docs link to offical docs for the config object.

@markocikos
Copy link
Member Author

@izaera I force pushed changes, please take a look. In addition, do you know what causes the
Pull Request Labeler / triage check failure? The error is quite cryptic to me, found unexpected type for label '10.x' (should be array of config options)

@markocikos markocikos changed the title feat(js-api): add types for Editor Config Contributor client extension feat(js-toolkit): add types for Editor Config Contributor client extension Dec 20, 2023
@markocikos markocikos changed the title feat(js-toolkit): add types for Editor Config Contributor client extension feat(js-api): add types for Editor Config Contributor client extension Dec 20, 2023
@izaera
Copy link
Member

izaera commented Dec 20, 2023

do you know what causes the Pull Request Labeler / triage check failure?

Looks like an internal issue in GH actions. I'd rerun it again.

on:
- pull_request_target
pull_request_target:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is what is making the CI task fail, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it still failed after that 😞 I'm trying to figure out what's going on, currently my best guess is that the latest version of https://github.com/actions/labeler requires different configuration.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I think I have this figured out:

  • Check is failing because v5 introduced new format for paths. Our version is currently set to main, which worked fine until two weeks ago when v5 released.
  • Check is still failing when I make the version fixed in PR, because it is still running actions/labeler@main

@izaera Any objections to merge the chore commit that sets version fixed to v4?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤷 I've never touched that part. If it works, push it 😅

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there is no way for me to know, before merging. It'll be fine, I'm sure

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leaving a note for @bryceosterhaus here. Setting of version from main to v4 fixes the labeler issue, but I'm not sure if it goes again some wider dependencies convention in this repo. If yes, then we can spend a bit of time updating configuration format to the latest version.

@izaera
Copy link
Member

izaera commented Dec 20, 2023

LGTM!

@markocikos markocikos force-pushed the LPS-204054 branch 3 times, most recently from 007130f to 2f632fb Compare December 20, 2023 11:49
@markocikos
Copy link
Member Author

@izaera Can you release new version of @liferay/js-api? I can try, but I'm not sure if I have permissions, or if there are and hidden quirks of this repo.

@izaera
Copy link
Member

izaera commented Dec 20, 2023

let me check 👍

@izaera
Copy link
Member

izaera commented Dec 20, 2023

It's as explained here -> https://github.com/liferay/liferay-frontend-projects/blob/master/projects/js-toolkit/CONTRIBUTING.md

I'll try it now bc it's been long since I don't release a version of this project, but IIRC there's nothing special with this project. Only that we are releasing pre-versions until we decide to make it effective and start to maintain proper versioning of the contracts.

@izaera
Copy link
Member

izaera commented Dec 20, 2023

There you go -> https://github.com/liferay/liferay-frontend-projects/releases/tag/js-api%2Fv0.6.0-pre.0

Next time you simply need to run the steps described in CONTRIBUTING.md.

As for the permissions, you should be fine because we set all our npm packages to the same user group (liferay devs), so you should have permissions too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants