v13 breaks `ember-cli-styles`

[boris-petrov]

It registers style: things and then one can look them up. This breaks when using ember-resolver v13. That is, doing style-namespace "foo-bar" returns a different thing than the one expected.

I can create a reproduction repo if that's going to help with debugging the issue.

cc @ef4

[boris-petrov]

So this happens because container-debug-adapter.js was removed in v13. And ember-cli-styles uses it to find all files with the scss extension. What's the path forward here?

[ef4]

Iterating all the files at runtime implies that all the files were forced to load into the browser. Which we don't want to commit to doing.

I don't fully understand why there are four different packages and how they relate and what they do, since none of them have content in their READMEs. But taking a guess here:

The addon knows every component's styleNamespace at build time: https://github.com/webark/ember-cli-styles/blob/f28e452889fbac1963c76ae01fe56f7974799304/packages/namespace/lib/style-info.js#L14

And the {{style-namespace}} helper already gets rewritten at build time into {{style-namespace "TheComponentName"}}:

https://github.com/webark/ember-cli-styles/blob/f28e452889fbac1963c76ae01fe56f7974799304/packages/namespace/lib/namespace-helper-ast.js

But that means it could instead be rewritten directly to the value of its styleNamespace, skipping the entire runtime registry.

There's no need for all those stub Javascript modules that export const styleNamespace = ... to exist, and then you won't need to use container-debug-adapter to find them.

[webark]

@ef4 First off 🫣🫥

Second, there are 4 packages cause the intent was to allow for a progressive approach, where one could could get co-location of styles without needing the namespace. And you could add backwards support for ember component css without needing it baked into the "name-spacing package". the other package was built to support using multiple css processors in a single app, and being able to incorporate them together.

The reason for needing to register the styles into the browser, was to support "auto route name-spacing". https://github.com/webark/ember-cli-styles/blob/f28e452889fbac1963c76ae01fe56f7974799304/packages/namespace/addon/utils/add-route-style-namespace.js#L8 it's been a long time since I was actively working one this.. But i'm pretty sure you don't need this if you just always use the helper (which is the path that would have to be taken to do the embroider support anyway (which was almost there, but they dealt with addon names differently that i never finished resolving).

But unless you have any ideas off the top of your head @ef4 , I don't think there's a way, (and could probably easily argue that you wouldn't want to) automatically add those computed properties to the controller in order to use in the route.

And I have no idea how this package will work in any of the modern ember paradigms as I've been out of ember :( for almost 4 years while i've been doing react 😭 and working with Backstage (which I do enjoy 😊)

I'm pretty sure ember-component-css doesn't work with any of this either. (this was supposed to be the "path forward" from ecc)