You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In alignment with the "no-arguments-for-html-elements." rule, we shall mandate that component imports in .gjs/.gts files follow PascalCase, instead of camelCase or any other casing. By following this approach, we can guarantee that we won't come across the error caused by casing at a later time.
Basically, by employing camelCase for component imports, we might encounter an error, ex:
// bad
import imageComponent from 'image/components/image-component';
import toggleButtonV2 from 'Buttons/components/toggles'
import something from 'x/components/y/z';
// good
import ImageComponent from 'image/components/image-component';
import { generateToken } from 'xxx/utils/tracking'; // not a component
The new rule will inspect whether the import pertains to a component. If it does, it will verify that the import is in PascalCase. Any component import in camel case or other casings will trigger an error.
Basically, the ImportDeclaration will be utilized to determine if an import comes from components (contains "components" in node.source.value) and subsequently assess whether the import (something like specifier.local.name )adheres to PascalCase.
Additional consideration: we have the option to allow configuration of the import path, with the default set to 'components.' rules: { 'ensure-components-imports-pascal-case': [ 'error', { importPaths:['**/components/**', 'xxx'] }, ], }
The text was updated successfully, but these errors were encountered:
@NullVoxPopuli We may just want to then update the rule no-arguments-for-html-elements which would incorrectly assume a lowercase angle bracket component is not an Ember component but an HTML element.
In alignment with the "no-arguments-for-html-elements." rule, we shall mandate that component imports in .gjs/.gts files follow PascalCase, instead of camelCase or any other casing. By following this approach, we can guarantee that we won't come across the error caused by casing at a later time.
Basically, by employing camelCase for component imports, we might encounter an error, ex:
// bad
// good
The new rule will inspect whether the import pertains to a component. If it does, it will verify that the import is in PascalCase. Any component import in camel case or other casings will trigger an error.
Basically, the
ImportDeclaration
will be utilized to determine if an import comes from components (contains "components" innode.source.value
) and subsequently assess whether the import (something likespecifier.local.name
)adheres to PascalCase.Additional consideration: we have the option to allow configuration of the import path, with the default set to 'components.'
rules: { 'ensure-components-imports-pascal-case': [ 'error', { importPaths:['**/components/**', 'xxx'] }, ], }
The text was updated successfully, but these errors were encountered: