chore: Lint#153
Conversation
| const schema = this.csdl[name] ?? {}; | ||
| const qualifier = schema.$Alias ?? name; |
There was a problem hiding this comment.
These changes became necessary due to the change from JSON.parse(JSON.stringify) to structuredClone. The former removes all properties with value undefined (which is not a valid JSON value), while the latter preserves them. So iterating over the keys of an object which was freshly cloned via JSON.parse(JSON.stringify) is guaranteed to not have keys pointing to undefined values.
| * @param {object} options | ||
| * @param {Paths} options.paths Paths Object to augment | ||
| * @param {string} options.prefix Prefix for path | ||
| * @param {Array} options.prefixParameters Parameter Objects for prefix | ||
| * @param {object} options.element Model element of navigation segment | ||
| * @param {object} options.root Root model element | ||
| * @param {string} options.sourceName Name of path source | ||
| * @param {string} options.targetName Name of path target | ||
| * @param {null | TargetRestrictions[]} options.target Target container child of path | ||
| * @param {number} options.level Number of navigation segments so far | ||
| * @param {string} options.navigationPath Path for finding navigation restrictions |
There was a problem hiding this comment.
this family of changes was introduced to satisfy the max-params rule. It also makes the call-sites easier to read, as arguments are now explicitly named.
| 'max-len': ['off'], | ||
| 'complexity': ['warn', 15], | ||
| 'max-params': ['warn', 4], | ||
| 'no-param-reassign': 'warn', |
There was a problem hiding this comment.
we have multiple places in which we apply some sanitisation to parameters as first step. I think it makes sense to allow this behaviour. Alternatives would be to either have // eslint-disable-nextlines, or to have constructs like
function foo (myParam) {
const mySanitisedParam = sanitise(myParam)
}Both feel odd to me, but I am open to discussing the matter, if removing the no-param-reassign rule is not an option.
1 participant
I noticed a multitude of lint warnings in the current code. This PR addresses most of them.
The only remaining warnings should come from the
complexityrule, for which we currently have 11 violations. The most complex function has a whopping complexity of 84 (getSchema)! I am not sure if that means that we should rework the offending functions, or if we should instead remove this rule from the rule set.