1. Using and Extending the Oracle JET Audit Framework
  2. Use the Oracle JET Audit Framework
  3. Run Audits on Oracle JET Applications

3 Run Audits on Oracle JET Applications

You can run an audit without making changes to the default Oracle JAF configuration or you can customize a variety of configuration properties to change audit behavior.

Audit the Application Using the Command Line

If you have configured Oracle JAF using the ojaf --init command, you can run an audit in the Command Prompt window.

In the JET application, open a Command Prompt window and from the root directory, use the JAF command without any arguments to run an audit based on the current JAF configuration for the entire application, against all HTML, JS, CSS, and JSON files.

ojaf

The full command line syntax is, with optional flags and an optional space-separated list of directory and/or file path arguments:

ojaf [ <flags> ] [ <files>]

The audit runs starting at the directory where you invoke the command in the Command-Line Interface. To audit a subset of the application files, change to the desired starting directory and invoke the audit command. Alternatively, for a simple audit, you can specify the files and file paths on the command line, relative to the current working directory:

ojaf myFile1[, myFile2, myFilex]
For example, you can audit two files in the current working directory and also audit all files in the subfolders of only the test directory like this:
ojaf file1 file2 ./test/**/*

Note that some platforms perform wildcard expansion of command line arguments, so you may need to quote ojaf argument with wildcard characters to prevent this.

The ojaf command accepts command line flags that you can use to override corresponding property settings in the JAF configuration file. For example, you can append the --format flag when you want to override the default flattened-out text output and display standard report style output for the audit. 

ojaf --format prose

Other command line flags allow you to interact with the ojaf utility to return desired information. For example, if you want to confirm the Oracle JET version of your application is among the current versions supported by JAF, append the --jetlist flag. 

ojaf --jetlist

You might also use the command line to get more details about a particular issue that your audit reported. This is supported by appending the --help flag and argument that provides either the ID of the message or the name of the rule that emitted the message. 

ojaf --help msgID

The complete list of command line flags can be displayed using the --help flag without arguments. 

ojaf --help

The --help command displays the command line flag options for the ojaf utility, as described in the table below. Note that Oracle JAF command line flags are case insensitive.

You can also use the --help flag to display the manual page (manpage) documentation for a command line flag by appending the flag as an argument to --help or -h, (such as ojaf -h dr).

Alternatively, you can display the manpage for a flag by ending the command with a ? (such as ojaf -rc?). Note that for *nix shells, the question mark should be escaped or the argument enclosed in quotes (ojaf -rc\? or ojaf "-rc?").

OJAF Command Flag (long/short) Description

--help

or

-h

Displays the usage of the command line flags described in this table.

--help msgId | rulename | command

or

-h msgId | rulename | command

Displays the description for a rule identified by its message ID or name, or displays the manpage for a command. For example, the following displays a description for the JAF audit message ID JET-0160:

ojaf -h JET-0160

The following displays the description for the JAF audit rule oj-html-binding-attr:

ojaf -h oj-html-binding-attr

The following displays the description for the JAF command line flag --retcode:

ojaf -h -rc

--<command>?

 Displays the manpage for a command, as an alternative to using -h <command>. For example, ojaf -h dr and ojaf -dr? both bring up the manpage for the command option --dryrun.

Note that for *nix shells, the question mark should be escaped or the argument enclosed in quotes (ojaf -rc\? or ojaf "-rc?") to avoid command line expansion.

--init

or

-i

Scaffold the oraclejafconfig.json file in the current directory. The configuration file is required to run an audit and can run with default settings or the settings can be changed to customize audit behavior.

--initRule rulename

or

-ir rulename

Scaffolds a skeleton custom audit rule implementation file in the current directory. The argument is followed by the rule name without the .js file extension. For example, the following creates a file my_new_rule.js in the current directory:

ojaf --ir my-new-rule

For details about creating user-defined, custom audit rules, see Set up the Custom Audit Rules Test Project.

--config filepath

or

-c filepath

Runs the audit with a specified configuration when followed by a file path to a configuration file.

If omitted, the current directory is searched for the oraclejafconfig.json file.

--jetver semver

or

-jv semver

Runs the audit for a JET release version when followed by a partial or full semantic version value representing the JET release version. Use to match the Oracle JAF rule set to the version of your application.

Accepts a partial semantic version definition, such that semver 9 will be promoted by JAF to the latest available release: 9.x.y. Similarly, semver 9.1 will be promoted by JAF to the highest patch level 9.1.y. For more semantic value examples, see Audit with Specific JET and ECMA Script Versions.

Tip:

Use the command ojaf --jetlist (or ojaf -jl) to display the current JET release versions supported by the ojaf Command-Line utility.

If omitted, the rule set is based on the version specified by the jetVer configuration property in the oraclejafconfig.json file.

--groups ruleGroupName1 ruleGroupName2 ...

or

-g ruleGroupName1 ruleGroupName2 ...

Runs the audit with the specified rule set groups. For the list of built-in rule set groups, see Audit with Specific Rules.

--format prose | line | json

or

-t prose | line | json

Formats audit output when followed by the output display format: prose for standard report style text output, line for flattened-out text output, or json for JSON format.

--outPath filepath

or

-o filepath

Writes the output of the audit to a specified directory when followed by a file path.

If the path is relative, the output directory is resolved relative to the current directory. If omitted, the audit output directory is the current directory.

--noout

or

-no

Suppresses output to the file specified in the configuration file by the outPath configuration property, and causes the audit output to be directed to the console.

--severity [ > | >= | < | <= ] blocker | critical | major | minor | info | all (default)

or

-s [ > | >= | < | <= ] blocker | critical | major | minor | info | all (default)

Note: If comparative operators are used, the severity condition must be enclosed by quotes.

Restricts the severity of the issues reported by the audit when followed by a severity level. For severity level descriptions, see Restrict Audit Rule Severity Level.

The optional comparative operators >, >=, <, and <= may precede the severity level (where the condition must be enclosed by quotes). For example, the following will display issues of severity "critical" and "blocker" level.

--severity ">=critical"

If omitted, the audit reports issues of all severity levels. If these have been redefined by using the configuration property sevMap, then a redefined severity may also be used here.

--followlinks

or

-fl

Audit follows the stylesheet <link> elements and JAF will audit linked-to stylesheets and referenced JavaScript/TypeScript script files.

If omitted, the audit follows the linked-to stylesheets by default.

--nofollowlinks

or

-nfl

Audit does not follow the stylesheet <link> elements and JAF will not audit linked-to stylesheets or referenced JavaScript/TypeScript script files.

--extra

or

-e

Shows extra details in the output. For example, it includes the rule that was used to create a particular issue, and the issue message ID.

--msgid

or

-id

When prose mode is configured, (see --format), the message ID of reported issues is appended to the displayed issue text.

A custom format defined by the JAF configuration property proseFormat overrides this flag.

--dryrun

or

-dr

Performs a full start-up and analysis of the configuration file. Displays the files that would have been audited, but does not fire the rules on the file set (as determined by the JAF configuration property settings files and exclude).

This is useful when you want to verify that the configuration file contains no errors and particularly useful when the settings for files and exclude properties are complex.

--jetlist

or

-jl

Displays the current JAF supported versions of JET.

This is useful when you want to verify that the version of JET used to create your application is among the versions supported by the current JAF installation.

--profiles

or

-prof [ profile name]

Displays the available configuration profiles that can be inherited. If the command flag is followed by an optional profile name, the profile is displayed.

--nslist

or

-nsl

Displays the namespaces known to JAF.

This is useful when you want to audit the file set for references to user-defined custom Web Components and need to suppress false audit reporting of valid Web Component references. For details, see Audit JET Custom Web Component Usages.

--dslist

or

-dl

Displays a list of the rules disabled by default in the JET built-in rule packs.

May be immediately followed by an optional pack prefix to limit the output to the pack declared.

--deplist

or

-dpl

Displays a list of the rules that are deprecated.

May be immediately followed by an optional pack prefix to limit the output to the pack declared.

--grouplist

or

-gl

Displays the built-in JET rule pack groups and their associated rules.

May be immediately followed by an optional pack prefix name to filter the output to the specified pack only.

--xgrouplist

or

-xgl

Displays external (non-JET) rule pack groups and their associated rules.

May be immediately followed by an optional pack prefix name to filter the output to the specified pack only.

Note that this command requires a configuration file with the rulePacks property set (that is, use of -c on the command line).

OJAF only refers to the rulePacks property, so no other properties need be present.

--amdlist

or

-amd

Displays the availability/unavailability of rules in AMD mode in JAF built-in rulepacks. An optional rulepack prefix may be specified to restrict output to just the specified pack.

--loadorder

or

-rlo

Displays the loading order of rules in JAF built-in rulepacks. An optional rulepack prefix may be specified to restrict output to just the specified pack.

--betalist

or

-bl

Displays the status of rules in JAF built-in rulepacks. An optional rulepack prefix may be specified to restrict output to just the specified pack.

--metahist

or

-mh

Displays the metadata history across all JET versions known to JAF, for deleted and renamed classes, and deleted class methods and members.

This is useful for diagnosing problems resulting from deprecation or name changes. Note JAF reports these in messages JET-3070 and JET-3071.

--dac

or

-dac

 Displays the active configuration file to evaluate the result of inheritance. No audit is performed.

--deflist

or

--default

or

-def

Displays the current JAF configuration default values for selected properties.

--debug

or

-d

Enables debug mode to allow very verbose output.

This is useful for diagnosing problems.

--rules

or

-r

Displays the active rules information and their options as text, but no audit is performed.

Can be used in combination with the --outPath flag to specify the file path to which rule data will be written. If omitted, rule data is written to the console.

--rulesjson

or

-rj

Displays the active rules information and their options as JSON, but no audit is performed.

Can be used in combination with the --outPath flag to specify the file path to which rule data will be written. If omitted, rule data is written to the console.

--rulessonar

or

-rs

Displays the active rules information and their options as XML (SONAR format), but no audit is performed.

Can be used in combination with the --outPath flag to specify the file path to which rule data will be written. If omitted, rule data is written to the console.

--retcode auto (default) | errors | x (a number)

or

-rc auto (default) | errors | x (a number)

Overrides the return code behavior of the OJAF command-line interface. Specify auto for the default behavior. Specify errors if the return code should be 0, except in the case of abnormal termination, where -1 will still be returned as in the default mode. Specify a number that will be used as the return code. Requires OJAF version 2.9.11 or later.

--help msgId | rulename

or

-h msgId | rulename

Displays the description for a rule identified by its message ID or name. For example, the following displays a description for the JAF audit message ID JET-0160:

ojaf -h JET-0160

The following displays the description for a JAF audit rule oj-html-binding-attr:

ojaf -h oj-html-binding-attr

--initRule rulename

or

-ir rulename

Scaffolds a skeleton custom audit rule implementation file in the current directory. The argument is followed by the rule name without the .js file extension. For example, the following creates a file my_new_rule.js in the current directory:

ojaf --ir my-new-rule

For details about creating user-defined, custom audit rules, see Set up the Custom Audit Rules Test Project.

Audit the Application with Predefined Runtime Options

Use the optional JAF configuration property options to define runtime options to use each time you run the audit from the command line.

Instead of invoking the ojaf command with command line flags, you can pre-define various runtime options by configuring the corresponding settings in the JAF configuration file options property. For example, instead of appending --extra --nocolor to an ojaf command invocation each time, you can define the configuration options debug and color.

To configure miscellaneous runtime options:
  1. To configure runtime options to apply to ojaf invocations, edit the oraclejafconfig.json file options property.
    "options": {
    "debug": true | false, // Set debug mode.
    "verbose": true | false, // Set verbose mode for additional output.
    "color": true | false, // Set color mode for messages and prose output. (Works best on a black background.)
    "msgid": true | false, // Add message IDs to displayed issues. (Requires 'format' : 'prose' | 'line'.)
    "ruleName": true | false // Add rule names and msgId's to displayed issues. (Requires 'format' : 'prose' | 'line'.)
    "retCode" | "rc": "auto" | "errors" | number // Override OJAF CLI return code. Default if omitted is "auto". See examples below.
}

    The command line equivalents are as follows.

    "options": {
    "debug": false, // Same as command line  -d   or -- debug
    "verbose": false, // Same as command line  -e   or --extra  
    "color": false, // Same as command line  -nc  or --nocolor
    "msgid": true // Same as command line  -id  or --msgid (Requires 'format' : 'prose' | 'line'.)
}

    Examples of the configuration option to override the return code behavior in the OJAF command-line interface. Requires OJAF version 2.9.11 or later. Note that "rc" and "retcode" are synonyms. 

    "options": {
    "rc": 0 // return code will always be zero
}

    or

    "options": {
    "rc": "errors  
    // return code will always be zero, except 
    // in the event of early/abnormal
}

    or

    "options": {
    "rc": "auto" 
    // default behavior - 0 - nnn -> number of issues found, 
    // -1 for early termination
}

Audit with Specific JET and ECMA Script Versions

During an audit, Oracle JAF refers to application-specific metadata to process the JAF rule set. Use the optional JAF configuration file jetVer property to set the metadata for a JET version and use the optional ecmaVer property to set the ECMA version. If the properties are omitted, then JAF processes the rule set by using metadata that is specific to the version of JET used to create the application.

The JAF built-in audit rule set works against metadata that is optimized for a specific version of JET and a specific JavaScript ECMA implementation. By default, JAF derives the rules metadata from the JET JavaScript API reference documentation that is specific to your application. However, you can customize the audit to process the built-in rule set for versions of JET and JavaScript/TypeScript other than your application.

  • Oracle JET version "5.2.0" (a quoted string) and later are valid settings for JET metadata. Note, if you happen to need to run with a JET release candidate, trailing characters are permitted, such as "9.0.0-rc3".

  • For the JavaScript ECMA, versions 5, 6, 7, 8, 9, 10, 11, 12, 13, and 14 (a number, without quotes) are valid and may be specified by the ECMA version number or ES version year, such as 2023 for ES14.

To change the application-specific metadata to use for an audit:
  1. To set the metadata for an Oracle JET release version by specifying a semantic version value, edit the oraclejafconfig.json file jetVer property.
    {
   ...
   "jetVer" :  "9.0.0"
   ...
}

    Must be a quoted string of JET release version "5.2.0" or later. The specification is treated by JAF as a semantic version value, where partial version specifications are valid. Generally speaking, only the major and minor release values are required (for example, "9" or "8.2"), since the patch number will be supplied by JAF. JAF promotes the specified jetVer value to the latest available JET release that corresponds to the semantic version (refer to the output of command ojaf -jl for the current default for the version of JAF you are using). For example, assume that JET release versions 8.1.1, 8.1.2, 8.2.1, and 8.2.2 are supported, then JAF promotes semantic version values for jetVer as follows.

    jetVer Value Promoted To JET Release
    "8" 8.2.2
    "8.1" 8.1.2
    "8.2" 8.2.2
    "8.2.0" 8.2.2

    Note:

    For more information about semantic versioning, visit the SemVer org website at https://semver.org.
  2. To set the metadata for a specific JavaScript implementation, edit the oraclejafconfig.json file ecmaVer property.
    {
   ...
   "ecmaVer" :  11
   ...
}

    A version number with or without quotes in the version range 5 to 14 (5, 6, and so on), or the year range 2015 to 2023 (2015, 2016, and so on).

    Starting in JAF version 2.9.15, the ECMA version can also be specified as an ES version year with or without quotes, such as 2020, 2019, and so on.

    Official Name / Version JAF ecmaVer Property JAF Version Required
    ES2023 / ES14 14 or "14" or 2023 or "2023" 6.9.0 or later
    ES2022 / ES13 13 or "13" or 2022 or "2022" 5.9.0 or later
    ES2021 / ES12 12 or "12" or 2021 or "2021" 5.9.0 or later
    ES2020 / ES11 11 or "11" or 2020 or "2020" 2.9.20 or later
    ES2019 / ES10 10 or "10" or 2019 or "2019" 2.9.11 or later
    ES2018 / ES9 9 or "9" or 2018 or "2018" 2.8.21 or later
    ES2017 / ES8 8 or "8" or 2017 or "2017" 2.8.21 or later
    ES2016 / ES7 7 or "7" or 2016 or "2016" 2.8.21 or later
    ES2015 / ES6 6 or "6" or 2015 or "2015" 2.8.20 or earlier
    na / ES5 5 or "5" na

Audit with Specific Rules

The audit rule set invoked by JAF can be optionally conditioned by the use of the configuration properties groups, ruleNames, and ruleMods. These properties provide different ways to enable and disable rules in the runtime rule set to specify a list of rules that will be run, and thus indirectly disable all other rules.

All JAF rules are defined in rule packs. Some rule packs are built-in to JAF and can simply be selected by setting the configuration properties starting with builtin. For example, builtinJetRules can be set to true, and all (enabled) rules defined in it now become available to JAF. (Note that builtinJetRules is true by default if omitted, and thus nothing needs to be declared to perform a standard audit using the JET built-in rules.) For rule packs that are not among the JET built-in rule packs, the configuration property rulePacks can be used to declare which external rule packs are to be loaded.

So, by default, the built-in Oracle JAF rule pack is enabled and, optionally, external rule packs may be loaded, and all rules within these rule packs are enabled to run in an audit. It is possible to disable rules in the rule pack to prevent the rule from running, but if the requirement is to run only a few rules, you may find it easier to state which rules are to be run rather than disable all those not required.

Use the JAF configuration property ruleNames to specify a list of specific rules and rule groups to run, and thus indirectly disable all other rules. Alternatively, use the property groups to specify a list of rule groups to run, and thus indirectly disable all other rule groups. Only the named rules or rule groups will be invoked in the JAF audit.

Note that the groups and ruleNames configuration properties alone do not enable rules, they only declare rules that you intend to use. Whether these rules are run or not may depend on the audit configuration. If, for example, a group is specified, but its containing rule pack is not loaded, the group's rules will not be run. Similarly, if a rule that's declared in ruleNames is disabled by default (or is disabled elsewhere via the ruleMods property), the rule will not run.

Thus, the ruleNames and groups property give you a convenient way to temporarily override an existing configuration of loaded rule packs without resorting to editing or commenting out configuration entries. This is particularly useful during rule development or debugging. These properties are also useful sometimes to state the rules to be run, rather than disable the rules you don't want run.

To audit with specific rules:
  1. To declare subsets of the rules to run, edit the oraclejafconfig.json file groups property.
    { "groups" : ["ruleGroup1", "ruleGroup2", ...],
}

    In the case of the JET built-in rules, you can specify the rules to run by declaring the group name for the built-in JET rule pack subset as described below. For example, where the group name jet-html defines the HTML rules and the group name jet-js defines the JavaScript/TypeScript rules, then the sample enables only the rules belonging to the group jet-html. 

    { "groups" : ["jet-html"],
}
    Built-in Rule Group Name Usage
    jet-html Rules check HTML.
    jet-css Rules check CSS.
    jet-js Rules check JavaScript.
    jet-ts Rules check TypeScript.
    jet-tsx Rules check TypeScript with JSX.
    jet-md Rules that check Markdown.
    jet-json Rules check JSON.
    jet-override Rules that check for CSS overrides.
    jet-perf Rules that check performance.
    jet-aria Rule check accessibility compliance.
    jet-deprecated Rules check deprecated status.
    jet-deleted Rules checking deleted status.
    jet-bp Rules enforce JET development best practices.
    jet-redwood-bp Rules that enforce best practices for Redwood.
    jet-csp Rules check for Content Security Policy (CSP) violations.
    html5 Rules check for obsolete tags and attributes for HTML5.
    jet-cca Enforces rules defined by Web Component metadata whether they exist in the application or on Oracle Component Exchange.
  2. Optionally, to declare custom rule groups to run, edit the oraclejafconfig.json file defGroups property and add the custom group name to the groups property.
    "groups": [
    "pages"
] // references a custom group

"defGroups": [
    {
        "pages": [
            "jet-html",
            "jet-css"
        ]
    },
               ...
]

    In the sample, the custom group pages is defined in the defGroups property and enabled for auditing in the groups property.

  3. To declare a list of specific rules and rule groups to run, edit the oraclejafconfig.json file ruleNames property.
    { "ruleNames" : ["ruleName1", "ruleName2, "ruleGroup1", ...],
}

    A rule or rule group name may be declared using a regular expression string that includes wildcard characters (requires JAF version 2.9.29 or later). 

    { "ruleNames" : ["oj-ruleName-*", ...],
}

    The ruleNames property and the groups property are mutually exclusive. If the ruleNames property is configured, only the rules and rule groups defined in it are active.

  4. To enable or disable specific rules and rule groups, edit the oraclejafconfig.json file ruleMods property and set the desired list of rules and rule groups on the enable and disable sub-properties.
    "ruleMods": {
    "enable": [
        "rule1",
        "rule2",
        "rulegroup1"
    ],
    "disable": [
        "rule3",
        "rule4",
        "rulegroup2"
    ]
}

    Note that because a rule group name represents a set of rules, the group name can be declared. If both enable and disable properties are declared, the enable set is processed first, followed by the disable set.

    Alternatively, if you are overriding rule options with ruleMods, then you can specify the enabled property of the desired rule as true or false on the rule definition. In this example, the rule is disabled. 

    "ruleMods": {
    "JET": {
        "oj-html-ko-databind": {
            "enabled": false
        },
    ...
    }
}

Audit with Custom Rule Packs

Use the Oracle JAF configuration property rulePacks to include sets of user-defined, custom audit rules in an Oracle JAF audit.

You can optionally enable sets of user-defined, custom audit rules by using the rulePacks property. The property specifies the zip file or folder containing the rules. For details about how to use Oracle JAF to create user-defined rules, see Extend the Oracle JET Audit Framework. 

"rulePacks": [
    {
        "path": "path/to/myrulepack.zip",
        "enabled": [
            true (default) | false
        ]
                  "status": [
            "all" (default),
            "production",
            "deprecated",
            "beta",
            "alpha"
        ]
    },
    {
        "path": "path/to/my/rulepack/folder",
        "enabled": [
            true (default) | false
        ]
        "status": [
            "all" (default),
            "production",
            "deprecated",
            "beta",
            "alpha"
        ]
    },
   ...
]

The enabled property is optional and provides the ability to easily disable a complete rule pack. If omitted, the default is enabled.

The specified path can be relative. If relative, it is considered to be relative to the location of the configuration file, or the configuration file's base property, if defined.

To audit with specific rule packs:
  1. To enable custom rule packs to run, edit the oraclejafconfig.json file rulePacks property, specify path as location of the rule pack and set the desired value for the optional status sub-property.
    "rulePacks": [
    {
        "path": "path/to/myrulepack1.zip",
    },
    {
        "path": "path/to/myrulepack2.zip",
        "status": [
            "deprecated",
            "beta"
        ]
    }
]

    The sample enables the audit to run with custom rule packs specified by the path properties. The enabled property is by default true and can be omitted. The status property for myrulepack2.zip in this sample limits the audit to load only rules with the system property status defined as deprecated or beta in the rules declaration file rules.json. For more information about system properties defined by a custom rule pack that you may override, see Configure Audit Rule Runtime Properties.

  2. To disable a custom rule pack from running, edit the oraclejafconfig.json file rulePacks property, specify path as the location of the rule pack and set the value false for the enabled sub-property.
    "rulePacks" : {
                  "path" : "path/to/myrulepack1.zip",
                  "enabled" : false
                }
    "rulePacks": {
    "path": "path/to/myrulepack1.zip",
    "enabled": false
}

    The sample overrides the enabled system property for a rule pack by disabling the rule pack specified by path.

  3. To disable all built-in JET rules and run the audit with only custom rule packs, edit the oraclejafconfig.json file and set the builtinJetRules property to false, and then edit the rulePacks property, as described above to enable the desired custom rule packs.
    "builtinJetRules" : false

    The sample overrides the builtinJetRules property to disable all the JET rules provided with the Oracle JAF installation.

Audit Only HTML Files that Contain Oracle JET Components

Use the optional Oracle JAF configuration file property jetPagesOnly to surpress auditing of an HTML file if the page does not contain any Oracle JET custom elements. If the property is disabled, then JAF processes and reports issues on all HTML files in the application.

When enabling auditing of Oracle JET only pages, JAF examines all elements in the page after parsing and before firing any rules. Thus enabling the jetPagesOnly property is less performant than when the property is disabled.
To audit only pages with Oracle JET components:
  1. To change the audit to ignore pages without JET components and audit only pages with JET components, edit the oraclejafconfig.json file jetPagesOnly property.
    {
   ...
   "jetPagesOnly" :  true
   ...
}

Audit JET Custom Web Component Usages

Because Oracle JET Web Components are user-defined, auditing their custom HTML depends upon processing the Web Component's metadata before auditing can begin. Use the optional JAF configuration properties components and componentsUrls to enable auditing support for such custom HTML elements by informing JAF where to find and extract Web Component metadata.

Oracle JET custom Web Components in your application rely on the component.json file to define metadata for their API, including their tag names and supported properties, methods, and events. When you want JAF to process rules specific to Web Components, you must set the JAF configuration components property for local Web Components to inform JAF where to find the component.json file.

During its pre-process phase, JAF recursively searches the specified locations to extract the component metadata. After this initial phase, the configuration properties are no longer needed and in subsequent phases of the audit, the previously extracted component metadata is used by the built-in JET rules defined by the jet-cca group to resolve Web Component references.

Although not a complete review of the JAF rules in the jet-cca group, once properly configured, JAF will enforce implementation details such as the following.

  • Check that components don't use a reserved namespace prefix (such as, oj-).
  • Check that for attributes are prefixed and point to an expression.
  • Checks that hardcoded element IDs are not used within the component implementation.

Because user-defined Web Components are associated with a namespace to avoid naming collisions, JAF needs to be informed about the namespace to prevent reporting references in the audit file set as not valid. By convention, the prefix of the Web Component name identifies the namespace. To declare the namespace for Web Components not defined by the oj namespace, you set the JAF configuration property nameSpaces.

To support auditing of Web Components:
  1. To set the component.json file path for Web Components that reside within the application, edit the oraclejafconfig.json file components property.
    "components" : ["path/to/my_components"]

    The property may be specified as a single string, or as an array of strings, where each folder is inspected, and a search is made for component.json files at the top level and recursively down through all child levels. 

    "components": [
    "path/to/my_components/group1",
    "path/to/my_components/group2"
]
  2. Important: Set the file property to include the folder paths of locally referenced Web Components.
    "files": [
    ...
    "./components/**"
]
  3. Suppress false reporting of valid references to Web Components by editing the oraclejafconfig.json file nameSpaces property and declare the list of allowed namespaces.
    "nameSpaces" : [ "my-foo", "my-bar", ... ]

    The namespace of user-defined Web Components is by convention the prefix you assigned the component to avoid naming collisions. In this example, Web Components with the prefixes my-foo and my-bar will not be flagged by the JAF audit when referenced in the file set.

    Tip: You can list the namespaces known to the JAF version you are running by entering this ojaf command:

    ojaf --nslist
  4. (Optionally) Suppress validation of Web Component metadata if you do not want the current component.json file schema to be applied during the pre-audit phase.
    "components":  ... ,
"componentOptions": {
    "applySchema": false
}

    This can be useful to prevent JAF-INIT messages from being displayed if the schema pass identifies component metadata issues.

  5. (Optionally) To enforce a maximum number of Web Components to exist in an HTML page, edit the oraclejafconfig.json file ruleMods property, specify the prefix of the built-in rule pack JET, and customize the built-in oj-html-cca-count rule specification.
    "ruleMods": {
    "JET": {
        "oj-html-cca-count": {
            "thresholds": {
                "oj-table": 5
            }
        }
    }
}

    The threshold for allowed Web Components in an HTML page is any number. For example, this sample checks the number of tables on the page.

    Component specifications can include wildcard characters. For example, this sample checks for all gauges and buttons, in addition to the oj-table component, and also limits the total number of components used by using the $total property. 

    "ruleMods": {
    "JET": {
        "oj-html-cca-count": {
            "thresholds": {
                "oj-table": 5,
                "oj-*-gauge": 10,
                "oj-buttonset-*": 10,
                $total: 20   
            }
        }
    }
}

    An invalid rule option will prevent Oracle JAF from running the oj-html-cca-count rule. Confirm that the option thresholds has been specified correctly.

Audit JET Custom Web Component Projects

You can run an extended audit over the Web Component project that you created using the Oracle JET Tooling by enabling the rule set builtinJetWcRules in the JAF configuration file.

Before you share a custom Web Component that you create, you can audit the standalone JET project that implements the Web Component. The rule set builtinJetWcRules is provided specifically for component developers to use to validate best practices and other concerns that guarantee the validity of Web Component implementation details.

The builtinJetWcRules rule set is defined by a number of audit groups that you can enable individually for fine control over the rules to invoke. For example, you might enable the rule group jetwc-pre-release just before the cut to production. The rule set also contains rules that you can configure specific to your project. All rule groups and individual rules with the groups are defined by the prefix jetwc.

To run the audit on your Web Component project, the project must be a standard JET project that you created as the source for your custom components. Specifically, the rule set expects the organization of the project folders to be consistent with the organization created by Oracle JET CLI when you create a new component or pack of components, using the ojet create component and create pack commands.

The builtinJetWcRules rule set enforces implementation details such as the following.

  • Checks that the folder structure and component names within the folders are as expected by the Oracle JET Tooling, and checks other such structure-related concerns.
  • Checks the validity of dependency relationships between components, including semvar values, JET version values, requireJS paths, and component API implementations.
  • Checks for consistency and correctness of component APIs in the namespace of your custom component, and that non-template slots are declared, events are declared, and that properties are nested only to a specified level—to identify just a few of the many API audit concerns.
  • Checks for deprecated API styles, usages, and practices in JET.
  • Checks for NLS support to verify the root language bundle location and that translation bundles have been provided for the specified locales.
  • Checks for issues related to theme-able components, such as the presence of the ojcss! plugin.
  • Checks for issues that can effect the usage of your component in Oracle Visual Builder, such as length limits for a display name that you define and the availability of a specified icon.
To enable auditing of Web Component projects and configure customizable rules:
  1. To enable the builtinJetWcRules, edit the oraclejafconfig.json file. This is a basic configuration for a Web Components project:
    {
  "jetVer": "17.1.0",
  "base": "$jafcwd",
  "files": [
    "./src/**/*.html",
    "./src/**/*.js",
    "./src/**/component.json"
  ],
  "components": [
    "./src/js/jet-composites"
  ],
  "builtinJetRules": true,
  "builtinJetWcRules": true,
  "format": "json",
  "outPath": "audit-report.json"
}

    The files and components properties specify the paths found in the standard project folder structure, as generated by the JET Tooling. The $jafcwd macro sets the base directory to the one in which the audit is invoked.

  2. To declare subsets of the rules to run, edit the oraclejafconfig.json file groups property.
    { "groups" : ["ruleGroup1", "ruleGroup2", ...],
}

    In the case of the JET built-in rules, you can specify the rules to run by declaring the group name for the built-in JET rule pack subset as described below. For example, where the group name jetwc-structure defines the folder structure and jetwc-api defines the API usage rules, then the sample enables only the rules belonging to those groups. 

    { "groups" : ["jetwc-structure", "jetwc-api"],
}
    Built-in Web Component Rule Group Name Usage
    jetwc-structure Rules that check that the overall disk layout is as expected by the Oracle JET Tooling. This group should be enabled for most component sets.
    jetwc-dependencies Rules that verify the various dependency relationships between components both within and across packs. This group should be enabled for all component sets.
    jetwc-pre-release Rules to be run before you cut a production release.
    jetwc-api Rules that verify the consistency and correctness of your component APIs. This group should be enabled for all component sets.
    jetwc-vb Rules that specifically check for things that effect the Visual Builder usage experience of your components.
    jetwc-nls Rules relating to NLS support.
    jetwc-deprecations Rules that check for known deprecated usages.
    jetwc-theming Rules to enable if you are trying to create theme-able components.
  3. (Optionally) To verify a specified set of files exists in the project, edit the oraclejafconfig.json file ruleMods property, specify the prefix of the built-in rule pack JETWC, and customize the built-in jetwc-standard-files structure rule specification. Note that you must ensure that all files that you want to check for are listed.
    "ruleMods": {
    "JETWC": {
        "jetwc-standard-files": {
            "customOpts": {
                "files": [
                    "README.md",
                    "changes.txt",
                    "version.mf"
                ]
            }
        }
    }

    The jetwc-standard-files rule checks by default for the README.md and CHANGELOG.md files, but if you customize this rule, then you must list them.

  4. (Optionally) To impose some length limit for the displayName property when the Web Component will be used with Visual Builder, edit the oraclejafconfig.json file ruleMods property, specify the prefix of the built-in rule pack JETWC, and customize the built-in jetwc-displayname Visual Builder rule specification.
    "ruleMods": {
    "JETWC": {
        "jetwc-displayname": {
            "enabled": true,
            "customOpts": {
                "limits": {
                    "component": {
                        "length": 30,
                        "words": 4
                    },
                    "property": {
                        "length": 30,
                        "words": 3
                    },
                    "event": {
                        "length": 30,
                        "words": 3
                    },
                    "template": {
                        "length": 40,
                        "words": 8
                    }
                }
            }
        }
    }

    Note that the number of letters and words can be configured for components that appear in either the Component palette (Composites and Patterns) or in Visual Builder Application templates, as well as for Events and Properties in the Properties pane.

  5. (Optionally) To specify a list of requireJS paths used by define() or require() calls in your component that are to be assumed to be available, edit the oraclejafconfig.json file ruleMods property, specify the prefix of the built-in rule pack JETWC, and customize the built-in jetwc-require-paths dependency rule specification. For example to disallow JQuery and VB (Visual Builder) paths, remove them from the standardPaths list.
    "ruleMods": {
    "JETWC": {
        "jetwc-require-paths": {
            "enabled": true,
            "customOpts": {
                "standardPaths": [
                    "ojs",
                    "knockout",
                    "hammerjs",
                    "persist"
                ]
            }
        }
    }

    All other valid paths are derived from the declared dependencies of the component that owns the file being audited.

    The path "./" is always considered to be valid. The path "../" is always considered to be invalid.

    Take care when adding extra standard paths of your own and avoid adding a path that constitutes a dependency that is not shipped as a standard part of JET or Visual Builder. For such cases, your component needs to declare an explicit dependency to another component (for example, by using a reference or resource component).

  6. (Optionally) To ensure that nesting of Web Component properties do exceed the desired level, edit the oraclejafconfig.json file ruleMods property, specify the prefix of the built-in rule pack JETWC, and customize the built-in jetwc-property-nesting API rule specification. By default the rule checks property nesting does not exceed two child levels (also called sub-properties). To check for nesting beyond three levels of sub-properties, set depth to 4, as shown.
    "ruleMods": {
    "JETWC": {
        "jetwc-property-nesting": {
            "enabled": true,
            "customOpts": {
                "depth": 4
            }
        }
    }

    Nesting of properties beyond two child levels is not recommended. To disallow sub-property use all together you would set depth to 1.

  7. (Optionally) To ensure that translation bundles exist for a specified list of locales, edit the oraclejafconfig.json file ruleMods property, specify the prefix of the built-in rule pack JETWC, and customize the built-in jetwc-nls-languages NLS rule specification. JAF will invoke this rule only when you have configured the locales you want to check against.
    "ruleMods": {
    "JETWC": {
        "jetwc-nls-languages": {
            "enabled": true,
            "customOpts": {
                "locales": [
                    "fr",
                    "fr-ca",
                    "de",
                    "zh-Hans|zh-CN"
                ],
                "strict": false
            }
        }
    }

    Use the pipe (|) symbol to separate acceptable alternatives. For example, the sample shows either zh-Hans or zh-CN locale is acceptable.

    By default, the checking code is lenient, with case matching and underscore v's hyphen. You can set strict to true to force exact matching.

  8. To allow exceptions to the jetwc-css-scoping rule to include CSS in the component CSS without component tag scoping, include a configuration option with an array of scopes to ignore. For example, the following configuration option:
    "ruleMods" : {
  "JETWC":{
    "jetwc-css-scoping":{
     "enabled":true,
       "customOpts":{
         "ignoreScopes":["oj-sp-color-invert-bg"]
    }
  }
}

    Allows the inclusion of oj-sp-color-invert-bg in the component CSS without component tag scoping, assuming that the oj-sp-color-invert-bg class is in a parent of the component.

Audit JET Web Component Projects Containing VComponents

The builtinJetWcRules rule set supports the auditing of Web Component projects that use VComponent TSX files in addition to the JS and TS files used by conventional CCA components.

To enable the builtinJetWcRules and thus the custom component audits, you must edit the oraclejafconfig.json file and set builtinJetWcRules to true.

The builtinJetWcRules rule set expects that the web component is a standard JET project that was created as the source for your custom components. That is, the rule set expects that the context and folder organization of the project be consistent with projects created using the Oracle JET CLI tool.

In order to include TSX files in the project audit, a TypeScript compilation must first be run against the code. Therefore, there are some extra requirements for the JAF configuration oraclejafconfig.json file:

  • You must be running JAF 3.3.0 or later.
  • Your JAF configuration must include .tsx files in the files property array to ensure that VComponents are processed.
  • You must set the "typescript":{"compile":true} option in your JAF configuration. Without this, .tsx files will be skipped.
  • The project under audit needs to have populated node_modules, which includes @oracle/oraclejet, as the JET version used by the project is also used for compiling.
  • Your project must compile successfully before the audit can be run.

For a mixed Typescript CCA and VComponent project, your oraclejafconfig.json file should look similar to the following: 

{
  "jetVer": "17.1.0",
  "base": "$jafcwd",
  "typescript":{
    "compile":true,
  },
  "files": [
    "./src/**/*.html",
    "./src/**/*.ts",
    "./src/**/*.tsx",
    "./src/**/component.json"
  ],
  "components": [
    "./src/js/jet-composites"
  ],
  "builtinJetRules": true,
  "builtinJetWcRules": true,
  . . .
}

Audit CSS Styles and Web Components Styles

Use the optional Oracle JAF configuration property stylesets to create a whitelist of valid user-defined web component styles to enable auditing support for an undefined JET core style, a misspelled style name, or an unknown (to JAF) Web component style.

The configurable style rules in the built-in JAF rule set can emit accept or reject CSS style diagnostics. In order to allow JAF to accept valid user-defined styles for Web components, you can specify the list of supported Web component styles in the stylesets property. If Web component styles are not defined, JAF may return a false positive for a valid style.
To audit CSS styles and include valid Web component styles:
  1. To enable auditing of CSS styles that do not return a false positive for valid Web component styles, edit the oraclejafconfig.json file stylesets property and define an array of style names for the namespace of the Web component.
    "stylesets": [
    // For namespace "oj-xxx"
    "oj-xxx-color",
    "oj-xxx-bgcolor",
                . . .
  
	// For namespace "oj-yyy"
    "oj-yyy-foo",
    "oj-yyy-bar",
. . .
]

    The sample enables JAF to distinguish valid Web component styles from an undefined JET built in style, a misspelled style name, or an unknown (to JAF) Web component style.

  2. To enable auditing of CSS styles and specify the valid Web component styles in an include .txt file, edit the oraclejafconfig.json file stylesets property and add @include() with the file path of the style set lists.
    "stylesets" :  [
   @include('./stylesets/styleset-oj-sample.txt') ,    
   // trailing comma to terminate the included list (see below)
   @include('./stylesets/styleset-oj-foo-bar.txt')
 ],

    The sample specifies the location of the style set list for multiple Web components to disassociate their style lists from the configuration for easier maintenance of the style lists.

    A sample styleset-oj-sample.txt file might look like the following. Note that if no trailing comma terminates the style list, one can be added after the @include(), as shown above. 

    // oj-sample styles
"oj-sample-card-emp-image",
"oj-sample-card-emp-name",
"oj-sample-card-emp-initials",
"oj-sample-card-emp-title"    <-- no trailing comma
  3. (Optionally) To report deprecation details on a style that has been deprecated, edit the oraclejafconfig.json file styleset property and replace the style name with an object containing deprecated and optional since and note properties.
    // oj-sample styles
"oj-sample-card-emp-image",
{"deprecated" : "oj-sample-card-emp-name"},
{"deprecated" : "oj-sample-card-emp-initials", "since": "8.2.0", "note": "Replace with oj-xxx"},
"oj-sample-card-emp-title"

    The sample informs JAF to report a deprecated style diagnostic, where the since and note properties will be added to the message. 

    [10, 20] CSS class selector 'oj-sample-card-emp-name is deprecated.  // since/note properties not defined
[10, 20] CSS class selector 'oj-sample-card-emp-initials' is deprecated (since 8.2.0). Replace with 'oj-xxx' // props defined
  4. (Optionally) To enforce validation of JET styles on HTML elements (including JET built-in components) and custom web component elements, edit the oraclejafconfig.json file and customize the built-in oj-html-stylesel rule specification.
    "ruleMods": {
    "JET": {
        "oj-html-stylesel": {
            // these styles will not be checked in HTML and web component elements
            "ignore": [
                "oj-ux-*, "oj-fwk-*"]
            }
        }
    }

    Note:

    Starting in JAF 2.10.0, oj-html-stylesel replaces audit rules oj-html-style and oj-html-ojstyle by validating the CSS styles used in HTML elements, including JET core components, and custom web components.

    Checks for JET styles (begin with oj-) used in HTML class attribute styles, as well as in style metadata associated with custom web components, defined by JAF configuration properties components and componentsUrls. CSS styles must be valid JET style classes. You can configure the rule to ignore certain classes. The class strings are treated as regular expressions, thus wild card characters can be used.

  5. (Optionally) To enforce checks for deprecated JET styles, edit the oraclejafconfig.json file and customize the built-in oj-css-style-deprecated rule specification.
    "ruleMods": {
    "JET": {
        "oj-css-style-deprecated": {
            // all JET class selectors will be tested for deprecation, except these
            "reject": [
                "oj-form-*"
            ]
        }
    }
}

    Checks that CSS does not specify deprecated JET class selectors. The rule can be configured to accept or reject certain style selectors. The class strings are treated as regular expressions, thus wild card characters can be used. Property accept specifies that only the class selector(s) declared should be tested for deprecation. Property reject specifies that all JET class selectors should be checked for deprecation except those specified by it. The properties accept and reject are mutually exclusive.

  6. (Optionally) To enforce verification that CSS does not specify overrides of JET styles, edit the oraclejafconfig.json file and customize the built-in oj-css-style-override rule specification.
    "ruleMods": {
    "JET": {
        "oj-css-style-override": {
            // only these styles will be tested for overrides
            accept": ["oj-list*"]
        }
    }
}

    or

    "ruleMods": {
    "JET": {
        "oj-css-style-override": {
            // all styles will be tested for overrides, except these
            reject": ["oj-list*"]
        }
    }
}

    Checks that CSS does not specify overrides of JET styles. The rule can be configured to accept or reject certain style classes. The class strings are treated as regular expressions, thus wild card characters can be used. Property accept specifies that only the class selector(s) declared should be tested for deprecation. Property reject specifies that all JET class selectors should be checked for deprecation except those specified by it. The properties accept and reject are mutually exclusive.

    Note: If you require all .oj-* styles to be checked for overrides, then declare an empty reject array. Because all styles are checked, except for those defined in reject, the net effect is that all .oj_* styles are checked.

  7. (Optionally) To enforce checks for the use of CSS variables that have been overridden, and avoid their use, as a best practice, edit the oraclejafconfig.json file and customize the built-in oj-css-var-override rule specification.
    "ruleMods": {
    "JET": {
        "oj-css-var-override": {
            "var": {
                // 'ignore' is used to ignore any overridden CSS vars that match 
                "ignore": [
                    "^oj-foo"
                ] //  For example, ignore CSS vars starting with oj-foo
            }
        },
        "oj-css-style-bp-font": {
            "var": {
                // 'accept' is used to report only on overridden CSS vars that match 
                "accept": [
                    "^oj-foo"
                ] //  For example, report only CSS variables beginning with oj-foo
            }
        },
    }
}

    Optional CSS variable names using regular expression strings may be added to this rule's options to control the audit. For this rule, the rule option var can be overridden using configuration property ruleMods. The var property has two mutually exclusive sub-properties ignore, and accept.

  8. (Optionally) To enforce checks for color references in standalone CSS or in embedded in HTML <style>, edit the oraclejafconfig.json file and customize the built-in oj-html-style-bp-color and oj-css-style-bp-color rule specifications.
    "ruleMods": {
    "JET": {
        "oj-html-style-bp-color": {
            // only this CSS property audited for color references
            "accept": [
                "background-color"
            ]
        },
        "oj-css-style-bp-color": {
            // do not audit these properties for color references
            "reject": [
                "background-image",
                "border"
            ]
        }
    }
}

    Check for use of color references in CSS (standalone or embedded in HTML <style>). They may be configured to accept or reject the color references found on specific CSS properties. Property accept specifies that only the properties declared by it should be audited. Property reject specifies that all properties should be audited except those specified by it. The properties accept and reject are mutually exclusive.

  9. (Optionally) To enforce checks for the use of font-size and font-weight in standalone CSS or in embedded in HTML <style>, edit the oraclejafconfig.json file and customize the built-in oj-html-style-bp-font and oj-css-style-bp-font rule specifications.
    "ruleMods": {
    "JET": {
        "oj-html-style-bp-font": {
            // only this CSS font property will be audited
            "accept": [
                "font-size"
            ]
        },
        "oj-css-style-bp-font": {
            // accept font-size, but reject font-weight audits
            "reject": [
                "font-weight"
            ]
        }
    }
}

    Check for use of font-size and font-weight in CSS (standalone or embedded in HTML <style>). They may be configured to accept or reject the font references found on specific CSS properties. Property accept specifies that only the properties declared by it should be audited. Property reject specifies that all properties should be audited except those specified by it. The properties accept and reject are mutually exclusive.

  10. (Optionally) To enforce checks for the use of certain font-family values in standalone CSS or in embedded in HTML <style>, edit the oraclejafconfig.json file and customize the built-in oj-html-style-bp-font-family and oj-css-style-bp-font-family rule specifications.
    "ruleMods": {
    "JET": {
        "oj-html-style-bp-font-family": {
            // only this CSS font family will be audited
            "accept": [
                "Oracle Sans"
            ]
        },
        "oj-css-style-bp-font-family": {
            // ignore these
            "ignore": [
                "inherit",
                "initial"
            ]
        }
    }
}

    These rules may be configured to accept or ignore font family values found on specific CSS properties. Property accept specifies that only the font families declared by it should be audited. Property ignore specifies that all font families should be audited except those specified by it. The properties accept and ignore are mutually exclusive.

  11. (Optionally) To enforce checks for the use of CSS absolute length units in standalone CSS or in embedded in HTML <style> so that you may replace them with relative units, as a best practice, edit the oraclejafconfig.json file and customize the built-in oj-html-style-abs-units and oj-css-style-abs-units rule specifications.
    "ruleMods": {
    "JET": {
        "oj-html-style-abs-units": {
            "absunits": {
                // only px quantities > 2 will be audited 
                "px": 2,
                ...
            }
        },
        "oj-css-style-abs-units": {
            "absunits": {
                // all units other than px have a threshold
                "all": 2,
                // only px quantities > 2 will be audited 
                "px": 2,
                ...
            }
        },
    }
}

    Check for use of CSS absolute length units in CSS (standalone or embedded in HTML <style>). Optional quantity thresholds can be set for all or each units For example, if 2 is set as a threshold for "px", then only quantities whose absolute value is larger than the threshold 2 will emit diagnostics. For CSS rules, specific rule selectors may also be optionally configured via regular expressions. The two optional rule option properties are absunits and selectors. The selector property (for rule oj-css-style-abs-units only) has two mutually exclusive sub-properties: accept and ignore. Property accept specifies that only the properties in the rule block for the selector(s) declared should be tested. Property ignore specifies that any selectors that match should be ignored.

    For rule oj-css-style-abs-units only, the selectors property may be specified separately, or in conjunction with absunits to set the scope based on the selector classes in the rule. A selector string is a regular expression string. When absunits and selectors are both specified, they are considered to be an AND condition. In that case, only the units exceeding the specified threshold and matching the selectors list are reported. 

    "ruleMods": {
    "JET": {
        "oj-css-style-abs-units": {
            "absunits": { ...
            },
            "selectors": {
                // ignore absolute units in rule blocks with 
                // selector classes ending in "-image"
                "ignore": [
                    "-image$"
                ]
            }
        }
        "oj-css-style-abs-units": {
            "absunits": { ...
            },
            "selectors": {
                // ignore absolute units in rule blocks with 
                // selector classes ending in "-image"
                "accept": [
                    "-image$"
                ]
            }
        },
    }
}

Audit for Oracle JET Deprecated Functionality

By default the Oracle JAF configuration will process all rules of the built-in JET rule pack, including rules for detecting deprecated Oracle JET functionality. Use the optional groups property of the JAF configuration file to customize the audit to process only the rules related to deprecated functionality by adding the jet-deprecated rule group to the JAF configuration.

The jet-deprecated rule group when configured for an audit will alert you to the presence of functionality that has been deprecated for the JET release version that you have configured for JAF, including deprecated JET API methods and members, as well as deprecated JET custom HTML components. Although the processing of rules in the jet-deprecated rule group is dependent on the JET release version, you can expect rules similar to the following to apply to your application.
  • oj-js-ojcomp-deprecated - Deprecated JET component classes should not be instantiated.
  • oj-html-ojtag-deprecated - Deprecated JET custom components should not be used.
  • oj-js-comp-attr-deprecated - Deprecated JET component class attributes should not be referenced. This rule's scope is configurable by the JAF configuration file ruleMods property, as described below.
  • oj-js-comp-meth-deprecated - Deprecated JET component class methods should not be invoked. This rule's scope is configurable by the JAF configuration file ruleMods property, as described below.
  • oj-html-ojattr-deprecated - Deprecated JET component attributes should not be used.
  • oj-html-ojslot - Deprecated JET component <oj-slot> should not be used since it is a binding-only element, and not a full custom element with properties and methods that can be accessed.
  • oj-html-style-deprecated - JET component class attribute for deprecated CSS styles should not be used.
  • oj-css-style-deprecated - Deprecated JET CSS class selectors should not be used.
To audit deprecated functionality:
  1. To enable processing exclusively the jet-deprecated rule group for all audits, edit the oraclejafconfig.json file groups property.
    { "groups" : ["jet-deprecated"]
}

    JAF audits will process only the jet-deprecated rule group until the groups property setting is changed or until overridden for a single audit from the ojaf utility command line.

  2. Alternatively, to enable processing exclusively the jet-deprecated rule group for a single audit (without editing the configuration file), enter the following ojaf command.
    ojaf --groups jet-deprecated

    A command that you enter in the command-line overrides the corresponding property setting in the JAF configuration file for the duration of the current audit.

  3. To configure the scope of the audit rules that check for deprecated/deleted members and methods, edit the oraclejafconfig.json file ruleMods property, specify the prefix of the built-in rule pack JET, and set the deprecated and deleted sub-properties of the scope property by specifying the enabled status for the sure and unsure confidence level options.
    "ruleMods": {
    "JET": {
        "oj-js-comp-attr-deprecated": {
            "scope": {
                "deprecated": {
                    "sure": true,
                    "unsure": false
                },
                "deleted": {
                    "sure": true,
                    "unsure": false
                }
            }
        },
        "oj-js-comp-meth-deprecated": {
            "scope": {
                "deprecated": {
                    "sure": true,
                    "unsure": false
                },
                "deleted": {
                    "sure": true,
                    "unsure": false
                }
            }
        }
    }
}

    The sample shows the default values for the confidence level options sure and unsure as specified by using the ruleMods property to configure the audit rules that detect deleted/deprecated members/functions. During static analysis of JavaScript/TypeScript, it may not be possible to determine with confidence the contents of obj in obj.fn() and obj.mem. This can cause the rules to be noisy in the case where a known deleted/deprecated member/function has been detected, but the rule has low confidence in the contents of obj. To reduce noise in the audit report, the scope of these rules can be configured by setting the confidence level for the audit. All properties are optional. For more details about the ruleMods property, see Configure Audit Rule Runtime Properties.

  4. To view long descriptions of the rules in the jet-deprecated rule group, enter the following ojaf command.
    ojaf -r