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(cloud-templates): add linter plugin #3

Merged
merged 5 commits into from
Jul 10, 2023
Merged

feat(cloud-templates): add linter plugin #3

merged 5 commits into from
Jul 10, 2023

Conversation

marstamm
Copy link
Collaborator

@marstamm marstamm requested a review from a team June 15, 2023 11:57
@marstamm marstamm self-assigned this Jun 15, 2023
@marstamm marstamm requested review from philippfromme and smbea and removed request for a team June 15, 2023 11:57
@bpmn-io-tasks bpmn-io-tasks bot added the needs review Review pending label Jun 15, 2023
node.id,
`${property.label} ${firstLetterToLowerCase(error)}`,
{
entryIds: [ getEntryId(property, template) ],
Copy link
Contributor

Choose a reason for hiding this comment

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

The structure of a report should be

{
  "propertiesPanel": {
    "entryId": "foo"
  }
}

according to @camunda/linting. I noticed that this structure is also assumed here. I'd like to change this so we have one structure instead of two.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I initially decided against this as one report can refer to multiple entries in the properties panel (eg. duplicated property error), which is why entryIds is an array.
The entryId set in the report which is used to focus is just the first from the array. Just adding a single entryId would not allow linter plugins to reference multiple property panel entries.

We could nest the entryIds option into the propertiesPanel and keep it side-by-side with the entryId:

propertiesPanel: {
  entryIds: ["foo", "bar"]
  entryId: "foo"
}

Alternatively, we can always keep the full list of entryIds for the properties panel and select the first one when we fire the event here. What do you think?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

For 2️⃣ , I created a draft PR in linting with the proposed changes: camunda/linting#63

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I adjusted the PR to aligned with 2️⃣ as of 201c4ec. Together with camunda/linting#63, this will align our report structure and allows linter plugins to supply more than one entryId

@bpmn-io-tasks bpmn-io-tasks bot added in progress Currently worked on and removed needs review Review pending labels Jun 26, 2023
* add bpmnlint
* add assert
* update to @camunda/[email protected]
* update to bpmn-js-properties-panel@2
@marstamm marstamm added needs review Review pending and removed in progress Currently worked on labels Jul 6, 2023
merge-me bot pushed a commit to camunda/linting that referenced this pull request Jul 7, 2023
};


export const ElementTemplateLinterPlugin = function(templates) {
Copy link
Contributor

@philippfromme philippfromme Jul 7, 2023

Choose a reason for hiding this comment

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

It took me some time to understand what's going on here. So basically we have a bpmnlint plugin buried in the the bpmn-js-element-templates project that is hidden in a file called Linter which isn't a linter but exports a rule and also a bpmnlint plugin. Maybe we can at least rename the file so it's less confusing.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Agreed, let's make the name clearer --> ba1d96e

The rule is only exported for the testing and not exposed in the final bundle. There, only the Plugin is exported:

export { ElementTemplateLinterPlugin as CloudElementTemplatesLinterPlugin } from './cloud-element-templates/LinterPlugin';

Copy link
Contributor

Choose a reason for hiding this comment

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

✔️

@philippfromme philippfromme self-requested a review July 10, 2023 07:41
Copy link
Contributor

@philippfromme philippfromme left a comment

Choose a reason for hiding this comment

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

@fake-join fake-join bot merged commit 2894943 into main Jul 10, 2023
5 checks passed
@fake-join fake-join bot deleted the Linter branch July 10, 2023 07:41
@bpmn-io-tasks bpmn-io-tasks bot removed the needs review Review pending label Jul 10, 2023
// We use the ElementTemplates Module without the required bpmn-js modules
// As we only use it to facilitate template ID and version lookup,
// access to commandstack etc. is not required
const elementTemplates = new ElementTemplates();
Copy link
Member

Choose a reason for hiding this comment

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

What can go wrong in the future here? 🙈

@nikku
Copy link
Member

nikku commented Jul 11, 2023

Nicely done 🏅

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