SDC should use dashes in file names

Is it that sdc is not enforcing a naming convention for template files that matches the current convention or are there already examples in tests or umami of component filenames that do not match the convention? If there are examples could you point to one in https://git.drupalcode.org/project/drupal, please?

As far as I understood the file names should include the component machine name. So that the have to use underscores instead of dashes as word separator.

You can see that in 11.x that although the dash is dominant that the underscore is quite common so sdc seems to be using the dominant one. If you want to open another ticket to suggest that we conform on a filename convention then feel free but it should certainly be an adjustment to the linting so that it doesn't rely on best effort.

$ find ./ -type f -name "*.twig" -exec basename {} \; | grep '-' | wc -l
656
$ find ./ -type f -name "*.twig" -exec basename {} \; | grep '_' | wc -l
95
$ find ./ -type f -name "*.js" -exec basename {} \; | grep '-' | wc -l
193
$ find ./ -type f -name "*.js" -exec basename {} \; | grep '_' | wc -l
70
$ find ./ -type f -name "*.css" -exec basename {} \; | grep '-' | wc -l
300
$ find ./ -type f -name "*.css" -exec basename {} \; | grep '_' | wc -l
96

I guess your find results include lots of third party files which does not follow Drupal naming conventions. Also files in tests can have any names.
I tried to collect all file names from Drupal core libraries using Library Manager module.

$discovery = \Drupal::service('library_manager.library_discovery');
foreach ($discovery->getLibraries() as $library) {
  foreach (['css', 'js'] as $type) {
    foreach ($library[$type] as $file) {
      if (\str_starts_with($file['data'], 'core/')) {
        echo \basename($file['data']), \PHP_EOL;
      }
    }
  }
}

The result is in attachment.

Not sure I understand how linting will help here. If you create a component named foo_bar the SDC will only look for foo_bar.css file, not for foo-bar.css file. Is it correct?

I think SDC should follow same approach as hook_theme. The hook names use underscores, but templates use hyphens.
https://git.drupalcode.org/project/drupal/-/blob/10.1.2/core/includes/th...

Not sure I understand how linting will help here. If you create a component named foo_bar the SDC will only look for foo_bar.css file, not for foo-bar.css file. Is it correct?

I'm getting ahead of myself, I apologise. I may suggest linting again but rather than me telling you what the "solution" is let's understand the problem. Thanks for reopening, I want to help here.

In order for this to be a bug there must be a specific or multiple files which do not conform to the naming convention already in core. Can you surface which ones they are. In the sdc module there are only tests. Although you point out that tests don't need to adhere to the same naming conventions surely the sdc module itself should set the example for how the components should be named and prepared.

The only other other example in core, that I'm aware of, is in the demo_umami theme.

Can you point to a js, css or twig template that is incorrectly named and then for each of those put the expected filename.

Can you point to a js, css or twig template that is incorrectly named and then for each of those put the expected filename.

SDC itself does not provide any components. There are a couple components in Umami profile but those are named with a single word.

The problem is that SDC requires that assets have same name as component machine name.
https://git.drupalcode.org/project/drupal/-/blob/10.1.2/core/modules/sdc...

I am assuming that machine name for a component should always use underscores. Though, technically it might me possible to create a component named foo-bar.yml. But in general the component name would be something like foo_bar.yml, so the corresponding asset name should begin with foo_bar. That means that foo-bar.css won't be registered as its name does not match machine name of the component.

Let me know if I am making to many assumptions.