`--environment=production` doesn't minify the generated class names

[boris-petrov]

I would expect that option to do that (it did in ember-component-css). Explicitly passing terseClassNames in ember-cli-build.js like so:

emberCliStylesOptions: {
  terseClassNames: true,
},

Also doesn't seem to have an effect.

[webark]

This is something that just needs to be implimented. It's basically there, just needs to pull the config in properly.

[webark]

@boris-petrov @hoIIer Do either of you know what the prescribed way of bringing in the current "environment" is? Right now it's doing

ember-cli-styles/packages/namespace/index.js

Line 21 in 9067ae6

terseClassNames: options.enviroment,

which comes from registry.app.options.environment but that's showing up as undefined. (still is undefined when you fix the spelling issue). It looks like we can pull it out of the app, so registry.app.env` is set. But this is only set for the app, not addons.

Now we can grab the "host app" and set it from what that is, however, when it comes to embroider, this will be prebuilt, so will have to figure out how to properly set this value when an addon is "pre-built" with embroider.

Do either of you know any addons that set configs based on the build time environment flag that are modern maintained addons?

[boris-petrov]

Not sure, perhaps ember-css-modules?

[webark]

I haven't seen what @dfreeman has done with the 2.0 version till just now. He did all the things that i was wanting to with adding the example apps and similar to the "plugin" model that this has adopted. i should sync up with him again about finding a path to were "css-modules" or "namespace" is aligned. His rewrite with using a complete registry implementation pattern is very similar as well.

I know this really isn't the place for this discussion, but @dfreeman we should probably have that discussion sometime again. i'll never be able to support this addon as much cause i don't work on ember anymore. But the desire to have a progressive approach from "co located styles" the to branch to "style namespace" or "css modules" would be so beneficial to the community...

Anyway... I'll look into the best way to pull in the environment. Sorry for that side rabbit trail.

[dfreeman]

I haven't seen what @dfreeman has done with the 2.0 version till just now.

The plugin registry system actually landed in our 0.x days back in 2017 😄

IMO while the registry made sense at the time and has had some useful applications, I think today these sorts of bespoke build systems are detrimental to the effort to move toward more ecosystem-standard tools that allow for front-loading most of the work to publish time rather than forcing host apps to repeat work to build all their dependencies.

With an eye toward Embroider and the v2 package spec, I'm actively working to move away from anything like a shared core Ember-specific style processing layer in favor of having folks directly use tools from the broader Web-dev ecosystem 🙂

If things shake out the way I expect, the future of ember-css-modules will likely just be some documentation pointing folks to use the CSS Modules support from their bundler (css-loader for Webpack, rollup-plugin-styles for Rollup, etc) along with an optional template transform to support local-class for folks who do want that last Ember-specific bit.

[webark]

@dfreeman hmmm.. that makes sense. So people would just use the css-loader or rollup-plugin-styles to pick up the colocated styles? So for something like this, which all really is wrapping the styles in a single style file with a namespace, and giving you access to that namespace in JS (which could easily be done manually, albeit annoyingly mind you) that would have to be some kind of webpack or rollup plugin that you could add in.

Hmm. I guess that works. CSS is in such a weird place these days anyway. soo.. 🤷 😞