Tailwind support

[vltansky]

@clydin few things that maybe will help you ensure full TailwindCSS support, based on issues we had in ngneat/tailwind:

1. Tailwind uses PurgeCSS under the hood, which is enabled when process.env.NODE_ENV is production, which Angular not setting by default.
   https://tailwindcss.com/docs/optimizing-for-production#removing-unused-css
   https://twitter.com/Nartc1410/status/1357504574479810568
2. Tailwind dark mode directives won't work correctly in component styles with view encapsulation other than none, as tailwind will just try to prepend class with .dark, so the result code will be something like .dark[_ng-content-**] .value[_ng-content-**]. Also not sure what will happen with ShadowDom, tested only with emulated. In ngneat/tailwind we made PostCSS plugin for it: https://github.com/vltansky/postcss-ng-tailwind-in-components. Probably there are alternative solutions.
   https://github.com/ngneat/tailwind/issues/54

relevant to: 73b4098

[dgp1130]

Thanks for bringing up these points! Glad we can draw from the experience of other tools to help craft an improved developer experience. We talked briefly about this in our tooling issue triage.

Regarding point 1: we're looking into an Angular-specific solution to be more comprehensive. Enabling PurgeCSS directly in Tailwind would likely not work well with Angular templates out of the box. We're hoping we can optimize this a little better with direct support in Angular.

Regarding point 2: ViewEncapsulation.None will be highly recommended with Tailwind due to the reasons you mentioned. View encapsulation doesn't really provide much value for Tailwind users anyways, since most styling is done via directly applied classes. We're hoping to avoid building additional tooling and over-engineer a solution where ViewEncapsulation.None would solve most of those issues.

[vltansky]

Just curious why not just to set NODE_ENV = production in production build ?

Looks like once it was added #2110

[clydin]

While a newly generated project does have a production configuration defined in the angular.json workspace file, the behavior is fully defined by the options present in the configuration. A developer could have a production configuration that has all optimization settings enabled, optimizes only scripts and not styles, performs no actual optimization, or anything in between. The production configuration is also completely optional and can be deleted or renamed while still allowing for an optimized build.

However, if Tailwind had a programmatic option (plugin constructor?) for setting its production mode (with a default to use the environment variable), the Angular CLI could potentially link that setting to the build system's style optimization settings.

[vltansky]

Thanks for the clarification. Make sense.

Tailwind has purge.enabled setting.
https://tailwindcss.com/docs/optimizing-for-production#enabling-manually
We used it in @ngneat/tailwind to enable PurgeCSS:
https://github.com/ngneat/tailwind/blob/158e7e62d66104a948f7536fd2bf400bd3d343db/libs/tailwind/src/add-tailwind-plugin.ts#L19

[nartc]

While a newly generated project does have a production configuration defined in the angular.json workspace file, the behavior is fully defined by the options present in the configuration. A developer could have a production configuration that has all optimization settings enabled, optimizes only scripts and not styles, performs no actual optimization, or anything in between. The production configuration is also completely optional and can be deleted or renamed while still allowing for an optimized build.

However, if Tailwind had a programmatic option (plugin constructor?) for setting its production mode (with a default to use the environment variable), the Angular CLI could potentially link that setting to the build system's style optimization settings.

This is actually a very good point. production in the context of angular.json is very arbitrary and it could mean absolutely anything based on the project/team. An additional option is probably the easiest way to allow the developers to determine whether to purge unused CSS or not with TailwindCSS's purge.enabled option.

With all this in mind, it would be helpful to also provide an option to opt-out of Tailwind support if the developers deem other tools (like ngneat/tailwind) is more helpful to them.

[beeman]

Please provide an opt-out in a patch release, this feature is breaking existing apps/installations and it's pretty interrupting.

I think this does not belong in a minor release as it's not backwards compatible.

[ahasall]

This is config I use:

module.exports = {
 purge: {
   enabled: process?.argv?.indexOf("build") !== -1,
   content: [
     "./src/**/*.html",
     "./src/**/*.ts",
     "./projects/**/*.html",
     "./projects/**/*.ts"
   ]
 },
 darkMode: false, // or 'media' or 'class'
 theme: {
   extend: {},
 },
 variants: {},
 plugins: [],
}

With this, when you run ng build, Purge CSS will be enabled. And for ng serve, you have the full set of Tailwind CSS utility classes.

[vltansky]

Looks like for now, the best way to opt-out from Angulars built-in Tailwind support and keep Taiwlind IntelliSense work in the same time is to rename tailwind.config.js to tailwind.js

The Angular CLI only references the file tailwind.config.js and the Tailwind IntelliSense extension looks for both tailwind.config.js and tailwind.js

#8427 (comment)

cc @nartc @beeman