In https://github.com/soxhub/ember-scoped-css/releases/tag/ember-scoped-css%400.16.0, typescript for loose mode was added, but it would be great to have the same TS support in strict mode / gts.

Today, ember-scoped-css is a v1 addon (with some v2esque things)
The advantage of the v1 addon is that it auto-installs itself, configures babel, and dumps all the CSS generated by it in to the vendor.css.

To migrate to a v2 addon, we'd want some structure like this:

• ember-scoped-css
  • runtime/
    • allows importing of the scopedClass helper
  • buildtime/
    • requires adding a babel plugin to your babel config
    • requires adding a webpack/unplugin plugin to put the generated CSS in the app's dist

new package: ember-scoped-css-compat

• uses ember-scoped-css to do v1 things like auto-installing

Due to the instability of ember-template-tag we should move to a more official implementation of template tag parsing with content-tag

Here is an example of it being used inside glint:
https://github.com/typed-ember/glint/pull/615/files#diff-0b42acfaca17e97c213ccfa6a2835c25e966bd2bf043799dad69d873828eb368L18-L23

See the logs here: #77

some-class is not replaced in the following scenario where class is concatenated.
class="some-class {{this.anotherClass}}"

Classes are renamed by adding postfix to class name. Postfix is generated by passing path to css file to getPostfix function. The problem is that full path of the css file is used ( for example: 'users//project/src/components/some.css'). We need to use only relative path in the addon.

given the CSS file app/components/foo.css

hbs and gjs files will compile appropriately. gts files will compile the component portion but not the css portion.

• app/components/foo.gts ❌
• app/components/foo.gjs ✅
• app/components/foo.hbs ✅

I tested this with both an embroider-strict and a classic-build app.

Update 3:

• no scoped (this is default, so to specify is redundant)
• :deep() for punching under the component boundary (such as when styling an external library)
• global CSS would not be in components, ideally, but could be left "as is" via global attribute.

const Other = <template>
  <style>
    .button {
      color: red;
    }
  </style>
  <button class='button'>non export</button>
</template>;

<template>
  <style>
    .button {
      color: green;
    }
  </style>
  <Other/>

  <button class='button'>Default export</button>
</template>

Update 2: I don't think it's a good idea to support <style> as a vanilla tag in gjs/gts -- we don't have the bandwidth to implement support for that across the 10+ syntax parsers that the community needs to support.

const Other = <template>
  <style scoped>
    .button {
      color: red;
    }
  </style>
  <button class='button'>non export</button>
</template>;

<template>
  <style scoped>
    .button {
      color: green;
    }
  </style>
  <Other />
  <button class='button'>Default export</button>
</template>

Update: per discussion below, in-<template> styles now have the scoped attribute.
We'd want to include a lint for folks to enable.

• forbid-global-style-tag or something like that -- that way folks can still do global styles in a component if they really want to

<style>
  .button {
    color: red;
  }
</style>

const Other = <template>
  <style scoped>
    .button {
      color: blue;
    }
  </style>
  <button class='button'>non export</button>
</template>;

const Another = <template>
  <style scoped>
    .button {
      color: green;
    }
  <button class='button'>non export</button>
</template>;

<template>
  <Other />
  <Another />
  <button class='button'>Default export</button>
</template>

There is a hardcoded extension to ignore in scoped-css-preprocessor.js.

It should be configurable in a config.

Background

As we wanted to support ember-scoped-css side by side with ember-css-modules we moved all css files to *.module.css. And setup an extension for ember-css-modules to module.css. This extension needs to be ignored otherwise the scoped-css-preprocessor will check if co-located components exist for those files and that can be time-consuming.

Example, all components share a style

<style>
  .button {
    color: red;
  }
</style>

const Other = <template>
  <button class='button'>non export</button>
</template>

<template>
  <Other />
  <button class='button'>Default export</button>
</template>

I've observed some funky behavior within the new addon, specifically around creating elements with a style class before the class exists, the template never receives the scoped class definition, even after the class has been created and the template has been changed. Additional classes don't necessarily trigger a scoped class name update, only in certain cases where the element has some specific changes to it.

1. Create a template file containing a div with a single style

// hbs
<div class="foo">foo</div>

2. Create an accompanying css file with the style for the div

// css
.foo {
 	color: red;
 }

3. Observe the rendered HTML does not have a scoped class name for foo

// html output
<div class="foo">foo</div>

4. Update the template file with a second div with a second single style

// hbs
<div class="foo">foo</div>
<div class="bar">bar</div>

5. Observe the rendered HTML after build has applied the scoped class name for foo

// html output
<div class="foo_ee3b6cad0">foo</div>
<div class="bar">bar</div>

6. Update the CSS file with a style definition for bar

// css
.foo {
 	color: red;
 }
 .bar {
 	color: green;
 }

7. Observe the rendered HTML after build to see there has been no change to the scoped class definitions.

// html output
<div class="foo_ee3b6cad0">foo</div>
<div class="bar">bar</div>

8. Save the template file with no changes

// hbs
<div class="foo">foo</div>
<div class="bar">bar</div>

9. Observe the rendered HTML after build to see there has been no change to the scoped class definitions.

// html output
<div class="foo_ee3b6cad0">foo</div>
<div class="bar">bar</div>

10. Add a single space character after "bar" and save the template file

// hbs
<div class="foo">foo</div>
<div class="bar">bar </div>

11. Observe the rendered HTML after build to see the first definition is scoped, but there has been no change to the second scoped class definition.

// html output
<div class="foo_ee3b6cad0">foo</div>
<div class="bar">bar </div>

12. Add a div with no styles after the "bar" div and save the template file

// hbs
<div class="foo">foo</div>
<div class="bar">bar </div>
<div>baz</div>

13. Observe the rendered HTML after build to see there has been no change to the scoped class definitions.

// html output
<div class="foo_ee3b6cad0">foo</div>
<div class="bar">bar </div>
<div>baz</div>

14. Add a "baz" style to the latest div and save the template file

// hbs
<div class="foo">foo</div>
<div class="bar">bar </div>
<div class="baz">baz</div>

15. Observe the rendered HTML after build to see there has been no change to the scoped class definitions.

// html output
<div class="foo_ee3b6cad0">foo</div>
<div class="bar">bar </div>
<div class="baz">baz</div>

16. Update the CSS file with a style definition for bar

// css
.foo {
 	color: red;
 }
 .bar {
 	color: green;
 }
.baz {
	color: blue;
}

17. Observe the rendered HTML after build to see there has been no change to the scoped class definitions.

// html output
<div class="foo_ee3b6cad0">foo</div>
<div class="bar">bar </div>
<div class="baz">baz</div>

18. Add a "foo" style to the last div and save the template file
```hbs
// hbs
<div class="foo">foo</div>
<div class="bar">bar </div>
<div class="baz foo">baz</div>

19. Observe the rendered HTML after build to see there has been no change to the second scoped class definition, but the third has updated.

// html output
<div class="foo_ee3b6cad0">foo</div>
<div class="bar">bar </div>
<div class="baz_ee3b6cad0 foo_ee3b6cad0">baz </div>

20. Add a second "bar" style to the second div and save the template file

// hbs
<div class="foo">foo</div>
<div class="bar bar">bar </div>
<div class="baz foo">baz</div>

21. Observe the rendered HTML after build to see there has been no change to the scoped class definitions.

// html output
<div class="foo_ee3b6cad0">foo</div>
<div class="bar bar">bar </div>
<div class="baz_ee3b6cad0 foo_ee3b6cad0">baz </div>

22. Add a fourth div with a "bar" style and save the template file

// hbs
<div class="foo">foo</div>
<div class="bar bar">bar </div>
<div class="baz foo">baz</div>
<div class="bar">biz</div>

23. Observe the rendered HTML after build to see there has been no change to the second scoped class definitions, but the new fourth div has generated a scoped definition.

// html output
<div class="foo_ee3b6cad0">foo</div>
<div class="bar bar">bar </div>
<div class="baz_ee3b6cad0 foo_ee3b6cad0">baz </div>
<div class="bar_ee3b6cad0">biz</div>

The second div with bar never updates, even though a newer div with the same style does. Definitely appears to be some sort of caching issue, hopefully these steps help!

I ran in to this as a laziness when copying the classic-app in #174
and without changing code, you can set name in ember-cli-build.js:

module.exports = function (defaults) {
  const app = new EmberApp(defaults, {
    name: 'classic-app',

and the modulePrefix in config/environment.js:

module.exports = function (environment) {
  const ENV = {
    modulePrefix: 'classic-app',

this works with all features of ember-cli, but the css preprocessor is expecting the name to match the package.json#name field (and likely other file filtering as well).

I'd consider this a bug -- but the work-around is easy enough for now (rename all your imports of the custom name to match the package.json#name)

This is missing functionality from original design document.

The linting rule will check if all css selectors from the CSS file are used in a co-located component.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update Node.js to v22.6.0
• Update devDependencies (@babel/eslint-parser, @ember/test-helpers, @nullvoxpopuli/eslint-configs, @typescript-eslint/eslint-plugin, @typescript-eslint/parser, ember-source, eslint-plugin-n, qunit, release-plan, typescript)
• Update pnpm to v9.7.1
• Update devDependencies (major) (@ember/string, @typescript-eslint/eslint-plugin, @typescript-eslint/parser, eslint, vitest)
• Lock file maintenance
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

ember-scoped-css puts all CSS files inside a layer with a hardcoded name. While it was expected for the first application where we used the ember-scoped-css, it should be configurable in config.

Requirement

It should be configurable if the transformed CSS is wrapped in a CSS layer.
The name of the CSS layer should be configurable.

Currently, CSS keyframes aren't scoped.

Requirement

keyframes in CSS files should be scoped with the suffix the same way as classes are renamed with suffix

The following CSS

@keyframe blink { ... }

will turn to

@keyframe blink_e1235345 { ... }

This will require that apps have an explicit babel config, or to set their babel plugins in their ember-cli-build.js

There have now been two PRs in which the effort to have "embroider compatibility" is far too much effort.

• #116
• #102

This due to how the embroider support is done via altering the wire-format of compiled templates.
We can't do this reliably, and this repo's upgrades are already held back as a result.
Here is one such example of the opcodes changing:

• glimmerjs/glimmer-vm@a5f2fbf#diff-157113fc4249c370a977d41c63cd2ece26045a68a9245a588d2766811a758896R12

We need to be using transforms from: https://github.com/emberjs/babel-plugin-ember-template-compilation/#common-options that would allow us to use the existing template-transform code from the classic app side of things and get rid of all the current wire-format mangling.
The wire format is not public API to us, and we can't ever expect that it's stable.

Discovered here: #107
during a yolo-upgrade of all embroider deps to latest, the tests fail with this error:

not ok 1 Chrome 117.0 - [82 ms] - Integration | Component | Alert from v2-addon: it has scoped class
  ---
  actual: >
    message 
  expected: >
    message_e4b9579df
  stack: >

Which is resolved when downgrading @embroider/addon-dev to v3.2.0.

This needs investigation, but here is the changelog to begin investigation:

• https://github.com/embroider-build/embroider/blob/main/CHANGELOG.md#release-2023-08-02-1
• in particular: embroider-build/embroider#1558

My babel.config.js:

module.exports = function (api) {
	api.cache(true);

	return {
		presets: [['@babel/preset-typescript']],
		plugins: [
			['@babel/plugin-transform-typescript', { allowDeclareFields: true }],
			'ember-template-imports/src/babel-plugin',
			'@embroider/addon-dev/template-colocation-plugin',
			['module:decorator-transforms', { runtime: { import: 'decorator-transforms/runtime' } }],
			'ember-concurrency/lib/babel-plugin-transform-ember-concurrency-async-tasks',
		],
	};
};

Rollup:

import { Addon } from '@embroider/addon-dev/rollup';
import { babel } from '@rollup/plugin-babel';
import json from '@rollup/plugin-json';
import { nodeResolve } from '@rollup/plugin-node-resolve';
import { defineConfig } from 'rollup';
import { glimmerTemplateTag } from 'rollup-plugin-glimmer-template-tag';

import { scopedCssUnplugin } from 'ember-scoped-css/build';

const addon = new Addon({
	srcDir: 'src',
	destDir: 'dist',
});

export default defineConfig({
	output: addon.output(),
	plugins: [
		json(),
		addon.publicEntrypoints([ /* ... */ ]),
		addon.publicAssets('public', { include: ['**/*.svg', '**/*.png'] }),
		addon.appReexports( /* ... */ ),
		babel({
			babelHelpers: 'bundled',
			extensions: ['.js', '.ts', '.gjs', '.gts'],
		}),
		nodeResolve({ extensions: ['.js', '.ts', '.gjs', '.gts'] }),
		addon.dependencies(),
		glimmerTemplateTag(),

		addon.hbs(),
		addon.keepAssets(['**/styles/*.css']),

		scopedCssUnplugin.rollup({ layerName: 'luna' }),

		addon.clean(),
	],
});

Right now we use the full file path to generate the suffixes that are added to class names i.e. /Users/superman/git/best-company/frontend/button-component.css but that means that suffixes won't be stable across different computers.

We should use the project-relative path (which could just mean path from the closest package.json 🤔) and that way the suffixes would be more stable 👍

Once

• #35
• and #34

Are implemented, this would provide an excellent one-stop for styles for the ember ecosystem for a variety of use cases, and would rival the capabilities of Svelte.
This would work well with a new "how to do CSS" in https://tutorial.glimdown.com
(this section isn't implemented in any form right now due to ember not having any way to do CSS)

Additionally, once implemented, we can RFC adoption to the app blueprint because of aforementioned variety of use cases.

In luna-core I have added a new component that uses scoped-class. The consuming application when using this component throws an error that scoped-class is not a helper. luna-core build is running (via pnpm start)

I'm guessing there's some build magic that the consuming app does that isn't working correctly for this setup.

What does that look like?

• Auditboard Security Review
• npm publishing process?
• License? Code of Conduct?
• ?