export const MyCustomThing: React.FC = ({ ruleResults: RuleResults }) => { return {ruleResults}; };
// End to end custom components
- Pretty formatter can render a checkup log
export const MyCustomThing: React.FC = ({ ruleResults: RuleResults }) => { return {ruleResults}; };
// End to end custom components
{ | |
"$schema": "http://json-schema.org/draft-04/schema#", | |
"title": "Static Analysis Results Format (SARIF) Version 2.1.0-rtm.5 Result Schema", | |
"id": "https://gist.githubusercontent.com/scalvert/290d11031f45854f11fd839ba6db9058/raw/sarif-result.json", | |
"description": "Static Analysis Results Format (SARIF) Version 2.1.0-rtm.5 Result JSON Schema", | |
"allOf": [ | |
{ | |
"$ref": "https://raw.githubusercontent.com/schemastore/schemastore/master/src/schemas/json/sarif-2.1.0-rtm.5.json#/definitions/result" | |
} | |
] |
Building SARIF logs manually using object literals, even with the assistance of types via @types/sarif
, can present some challenges to consumers. Maintaining the necessary log state while building reporting descriptors like rules
can become an exercise in object juggling.
The eslint formatter captures this quite well. It uses local variables to maintain state for properties, indices, and it utilizes these variables to "build-up" the log structure.
While this is a completely reasonable approach, having to duplicate this type of functionality in other static analysis tools seems like a heavy lift to have consumers adopt the SARIF standard.
Adding a TypeScript implementation of a builder will help consumers
import { _registerHook } from '@ember/test-helpers'; | |
import a11yAuditIf from 'ember-a11y-testing/test-support/audit-if'; | |
function getUrlParameter(name) { | |
const location = utils.getLocation(); | |
const regex = new RegExp('[\\?&]' + name + '=([^&#]*)'); | |
const results = regex.exec(location.search); | |
return results === null ? '' : decodeURIComponent(results[1].replace(/\+/g, ' ')); | |
} |
We have very precise rules over how our git commit messages can be formatted. This leads to more readable messages that are easy to follow when looking through the project history. But also, we use the git commit messages to generate the AngularJS change log.
Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:
import Ember from 'ember'; | |
export default Ember.Component.extend({ | |
}); |
a |
import Ember from 'ember'; | |
export default Ember.Component.extend({ | |
click() { | |
this.show(); | |
} | |
}); |
import Ember from 'ember'; | |
export default Ember.Component.extend({ | |
click() { | |
this.show(); | |
} | |
}); |
import Ember from 'ember'; | |
class MyModel extends Ember.Object { | |
constructor() { | |
super(); | |
this._first = "Ricardo"; | |
this._last = "Mendes"; | |
} | |
get first() { |