Tailwind support #20015

vltansky · 2021-02-10T09:18:03Z

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

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
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

The text was updated successfully, but these errors were encountered:

dgp1130 · 2021-02-11T19:21:56Z

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 · 2021-02-11T20:03:03Z

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

Looks like once it was added #2110

clydin · 2021-02-11T20:13:52Z

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 · 2021-02-11T21:01:17Z

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 · 2021-02-14T21:23:25Z

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 · 2021-02-16T03:13:01Z

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 · 2021-02-16T08:15:36Z

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 · 2021-02-16T09:10:54Z

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

devpato · 2021-02-17T07:34:43Z

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.

Hi! Thanks for sharing this. For your solution, I had to rename tailwind.config.js to tailwind.js for it to work. Otherwise, I was getting the following error:

Error: ./src/app/app.component.scss
Module build failed (from ./node_modules/postcss-loader/dist/cjs.js):
/Users/patriciovargas/Desktop/tw/tailwind.config.js:4
enabled: process?.argv?.indexOf("build") !== -1,

Then when I ran ng build --prod I didn't see any styles in my app. Any advice? Thanks!

Running Angular 11.2.0

module.exports = {
    prefix: '',
    purge: {
      enabled: true,
      content: [
        './src/**/*.{html,ts}',
      ]
    },
    darkMode: 'class', // or 'media' or 'class'
    theme: {
      extend: {},
    },
    variants: {
      extend: {},
    },
    plugins: [require('@tailwindcss/forms'),require('@tailwindcss/typography')],
};

I think the reason is based on @vltansky is because I'm ruinning node 12.13 :P

eweap · 2021-03-01T09:22:49Z

For those interested, this is what I end up with, to support @nrwl/nx commands and multiple projects names

purge: {
        // Workaround to run purge only during build task (see: https://github.com/angular/angular-cli/issues/20015)
        // This should match the nx build task name of any project:
        // ex: "app1:build:production" or "app2:build:staging"
        enabled: process?.argv?.some(arg => arg.includes(':build')),
        content: ['./apps/**/*.{html,ts}', './libs/**/*.{html,ts}'],
},

rnbrady · 2021-03-04T09:24:10Z

Great that this is being worked on but really confused me how my custom webpack config was being ignored and tailwind was somehow mysteriously being invoked. Since I'm new to Angular it took me hours to get to the bottom of it.

clydin · 2021-03-04T16:54:55Z

One of the primary motivations for providing support of Tailwind within the Angular CLI was to mitigate these type of confusing situations and similar problems for users moving forward, especially when updating their projects. While we do understand the confusion this may have caused for existing users of customized Webpack configurations, modification of the internal Webpack configuration via a custom builder is considered an experimental option. This means that no SemVer guarantees are provided regarding the content and structure of the internal Webpack configuration; and breaking changes regarding the Webpack configuration may occur in any version. Additionally, during the Angular update process, migrations may also be skipped or reduced in scope when unknown builders (with potentially unknown options and/or behavior) are present in the Angular configuration. These migration reductions may not be a problem in and of themselves as the migration may not apply to the unknown builder or the builder may provide its own migrations. However, it is something that may need to be evaluated during the update process. By officially supporting Tailwind, we hope to maximize the ability for users to continue using the official Angular builders while also allowing users to leverage their preferred tools such as Tailwind.

vltansky · 2021-03-04T17:07:13Z

@clydin could you take a look at the Purge PR please?

nartc · 2021-03-04T17:08:58Z

@clydin that makes total sense. Then should I take that as a no for AngularCLI providing an opt-out of Tailwind support? Just want to make sure so that we (ngneat/tailwind) can adjust our schematics so it wouldn't conflict with AngularCLI's official support.

Also on Tailwind official support, this is a great initiative from the Angular CLI team. However, supporting Tailwind but not supporting Purging is half-baked. TailwindCSS looks for either one of these two things to execute PurgeCSS:

NODE_ENV=production
purge: { enabled: true } in tailwind.config.js

AngularCLI doesn't set NODE_ENV to production on prod build which put the burden of come up with logic to set enabled on production build which can be very confusing and not straightforward. Is there consideration to provide a flag to explicitly say purgeTailwind or something like that? If this flag is turned on, AngularCLI will append enabled: true to purge in tailwind.config.js

ahasall · 2021-03-04T17:19:34Z

Just want to make sure so that we (ngneat/tailwind) can adjust our schematics so it wouldn't conflict with AngularCLI's official support.

@nartc do you plan to continue maintaining the integration via a custom Webpack config ?

nartc · 2021-03-04T17:32:15Z

Just want to make sure so that we (ngneat/tailwind) can adjust our schematics so it wouldn't conflict with AngularCLI's official support.

@nartc do you plan to continue maintaining the integration via a custom Webpack config ?

Yes. I've been on parental leave so haven't been updating the ngneat/tailwind package but after I'm back, we'll come up with a roadmap as to what ngneat/tailwind will provide moving forwards. That is also depends on AngularCLI team responses in this thread.

rnbrady · 2021-03-04T18:30:19Z

A workaround for the purge issue is:

NODE_ENV=production ng build --prod

One thing worth noting is that the paths in purge are resolved relative to the workspace root (regardless of which one contains tailwind.config.js). So if you have applications under a projects folder you should use:

  purge: [ "./projects/**/*.{html,scss,ts}" ]

Trying to glob everything like this:

  purge: [ "./**/*.{html,scss,ts}" ]

results in a much longer build time, presumably as a result of searching node_modules.

clydin · 2021-03-04T19:14:13Z

The ngneat/tailwind schematics are still a valuable source for setting up and integrating tailwind into a project. We hope that the two projects can work in concert.

For the purge setting, it would be preferred if Tailwind itself provided a more fine-grained method to specify its production mode. Two potential options for this are a programmatic option when initializing the plugin or a targeted environment variable (e.g., TAILWIND_ENV/TAILWIND_MODE/etc.). The NODE_ENV environment variable has the potential to effect the behavior of every active dependency involved in the build system.
If this is not viable, then loading the configuration file directly may be an option. However, it would be preferred that the structure of the Tailwind configuration object remain opaque to the Angular CLI. Not doing so presents supportability and sustainment concerns moving forward. One potential concept (that would still need further analysis) may be to provide additional context properties when loading the configuration file (for example, angular.configuration, angular.options, etc.). The ngneat/tailwind schematics could then use those when generating a Tailwind configuration file (purge: { enabled: angular?.options.optimization?.styles?.minify } or purge: { enabled: angular?.configuration === 'production' }). This would limit the necessary knowledge for the Angular CLI to a JavaScript file that exports an object that is passed directly to the Tailwind plugin. Again, this would still need further analysis.

For the :host-context item (number 2 in the original post), the class based dark mode (and potentially other similar future Tailwind features) is problematic not only in Angular view encapsulation scenarios but also ShadowDOM in general. It may be a better longterm option for Tailwind to have a ShadowDOM support option. This could generate the appropriate rules for all use cases that would be affected within Tailwind when using ShadowDOM or frameworks that emulate it.
As an aside, the postcss plugin mentioned above appears to directly add :host-context to the existing rule, this can be problematic on browsers that do not support the pseudo-class and, unfortunately, support is not ideal currently (https://caniuse.com/mdn-css_selectors_host-context). If the pseudo-class is not supported and any component is not using Angular's emulated view encapsulation (it can be configured per component), the entire rule can be dropped due to the invalid selector. Adding a second rule with the :host-context should avoid this problem.

vltansky · 2021-03-04T20:56:44Z

Looks like tailwind working on JIT compilation, that wouldn't need purge functionality / prod flags. Long term this can be the best solution. Although right now it's still experimental.

An experimental library that generates CSS with the same API you already know from Tailwind CSS, but on-demand as you author your template files instead of generating an extremely large stylesheet once when you start your build system.

This has the following advantages:

No long initial build time (Tailwind can take 3–8s to compile in isolation, and upwards of 30–45s in webpack projects)
No need to purge unused styles, since styles are generated as they are needed
Your CSS is identical in development and production, so there's no chance of accidentally purging a style you needed to keep
No need to explicitly enable variants, everything works out of the box since file-size isn't a limiting factor
No dev tools performance issues that stem from parsing large stylesheets
Current limitations:
These are all things we're actively working on, but aren't ready yet in this current pre-alpha release. This is > all stuff I expect will be ready by the end of next week :)
....
https://www.npmjs.com/package/@tailwindcss/jit/v/0.0.0-f5d1f58e

Regarding :host-context - sorry but I didn't get this part: "Adding a second rule with the :host-context should avoid this problem"?

clydin · 2021-03-04T21:11:18Z

Regarding the :host-context, using the following example from the plugin's unit tests:

.some-parent-class .test, :host-context(.some-parent-class) .test {}

This could instead be transformed as the following:

.some-parent-class .test {}
:host-context(.some-parent-class) .test {}

Some additional background: https://developer.mozilla.org/en-US/docs/Web/CSS/Selector_list#selector_list_invalidation

angular/angular-cli#20015 (comment)

dgp1130 · 2021-03-11T20:35:57Z

We talked a bit about the PurgeCSS issue in the CLI triage meeting today but haven't made a decision yet. I made a separate issue to look into the best way to provide build context to external tool config files: #20253. This problem applies to all possible external tools (though I think Tailwind is the first), so we want to be careful about how we approach the issue and make sure the approach is scalable and decoupled from the specific tools in the best possible way.

As others have mentioned, the simplest workaround for the PurgeCSS problem at the moment is to just set NODE_ENV on the command line. This may affect other tools in the build which is why we don't do it by default, but if it works for your project then there's no problem with using it.

NODE_ENV=production ng build --configuration production

We'll discuss this more soon and try to come up with a complete solution/recommendation.

zub0r · 2021-03-16T14:17:32Z

You probably already know, but this might be highly relevant, while getting rid of purge - tailwind JIT compiler.

dgp1130 · 2021-03-18T18:21:05Z

Had some more discussion about the PurgeCSS issue today, and our current plan is to hold out to see if Tailwind JIT is able to handle this problem on its own, without any direct Angular integration. We'll test out JIT and keep an eye on it for the time being rather than implementing a unique build context solution just for Tailwind.

adrian-goe · 2021-04-02T20:01:21Z

So it looks like JIT is now part of tailwind and will ship with version 2.1

tailwindlabs/tailwindcss#3905

https://twitter.com/adamwathan/status/1378054054107041792

lacolaco · 2021-04-06T05:19:49Z

FYI: This article nicely explains problems the CLI has currently around JIT mode.

https://apvarun.com/blog/tailwindcss-jit-in-angular

ahasall · 2021-04-06T07:56:12Z

Hello @lacolaco, this is what I use for the JIT mode and it works well for me:

process.env.TAILWIND_MODE =
  process.env.WEBPACK_DEV_SERVER === 'true' && process.argv.join(' ').indexOf('build') !== -1
    ? 'build'
    : 'watch';

module.exports = {
  mode: 'jit',
  purge: ['./src/**/*.{html,ts}', './projects/**/*.{html,ts}'],
  theme: {
    extend: {},
  },
  variants: {},
  plugins: [],
};

mightymatth · 2021-04-06T09:05:05Z

@ahasall,
I've installed the latest Tailwind version 2.1.1,
I get the following error with this configuration:

Error: ./src/styles/styles.scss
Module build failed (from ./node_modules/mini-css-extract-plugin/dist/loader.js):
ModuleBuildError: Module build failed (from ./node_modules/postcss-loader/dist/cjs.js):
TypeError: Cannot read property 'type' of undefined
    at AtRule.normalize (/Users/username/projects/myproject/node_modules/postcss/lib/container.js:313:22)
    at AtRule.append (/Users/username/projects/myproject/node_modules/postcss/lib/container.js:166:24)
    at AtRule.append (/Users/username/projects/myproject/node_modules/postcss/lib/at-rule.js:13:18)
    at /Users/username/projects/myproject/node_modules/tailwindcss/jit/lib/collapseAdjacentRules.js:26:21
    at Root.each (/Users/username/projects/myproject/node_modules/postcss/lib/container.js:60:16)
    at /Users/username/projects/myproject/node_modules/tailwindcss/jit/lib/collapseAdjacentRules.js:10:10
    at LazyResult.runOnRoot (/Users/username/projects/myproject/node_modules/postcss/lib/lazy-result.js:303:16)
    at LazyResult.runAsync (/Users/username/projects/myproject/node_modules/postcss/lib/lazy-result.js:355:26)
    at LazyResult.async (/Users/username/projects/myproject/node_modules/postcss/lib/lazy-result.js:205:30)
    at LazyResult.then (/Users/username/projects/myproject/node_modules/postcss/lib/lazy-result.js:190:17)
    at /Users/username/projects/myproject/node_modules/webpack/lib/NormalModule.js:316:20
    at /Users/username/projects/myproject/node_modules/loader-runner/lib/LoaderRunner.js:367:11
    at /Users/username/projects/myproject/node_modules/loader-runner/lib/LoaderRunner.js:233:18
    at context.callback (/Users/username/projects/myproject/node_modules/loader-runner/lib/LoaderRunner.js:111:13)
    at Object.loader (/Users/username/projects/myproject/node_modules/postcss-loader/dist/index.js:104:7)

@lacolaco, I also tried to add a postinstall script you mentioned from the blog post, but it seems it's incompatible with the newest v2.1 as they merged JIT plugin directly into Tailwind.

nartc · 2021-04-06T13:03:04Z

Hello @lacolaco, this is what I use for the JIT mode and it works well for me:

process.env.TAILWIND_MODE =
  process.env.WEBPACK_DEV_SERVER === 'true' && process.argv.join(' ').indexOf('build') !== -1
    ? 'build'
    : 'watch';

module.exports = {
  mode: 'jit',
  purge: ['./src/**/*.{html,ts}', './projects/**/*.{html,ts}'],
  theme: {
    extend: {},
  },
  variants: {},
  plugins: [],
};

hi @ahasall , I'm not able to get tailwindcss@2.1.1 with mode: 'jit' to work at all for HTML/TS files. Setting up a custom class with @apply works.

<button class="px-4 py-2 rounded bg-blue-400 text-white">Button</button>

This does not work but the following works. Any suggestions?

.btn {
   @apply px-4 py-2 rounded bg-blue-400 text-white;
}

<button class="btn">Button</button>

vltansky · 2021-04-06T20:10:35Z

@nartc add

@import 'tailwindcss/base';
@import 'tailwindcss/components';
@import 'tailwindcss/utilities';

to style.scss

example repo: https://github.com/vltansky/tailwind-jit-test

vltansky · 2021-04-07T06:03:44Z

ngneat/tailwind released v7 that leverage Angular CLI built-in support for, opt-in JIT and workaround for enabling purge
https://twitter.com/Nartc1410/status/1379662444906344449

mightymatth · 2021-04-19T18:51:15Z

@ahasall,
I've installed the latest Tailwind version 2.1.1,
I get the following error with this configuration:

Error: ./src/styles/styles.scss
Module build failed (from ./node_modules/mini-css-extract-plugin/dist/loader.js):
ModuleBuildError: Module build failed (from ./node_modules/postcss-loader/dist/cjs.js):
TypeError: Cannot read property 'type' of undefined
    at AtRule.normalize (/Users/username/projects/myproject/node_modules/postcss/lib/container.js:313:22)
    at AtRule.append (/Users/username/projects/myproject/node_modules/postcss/lib/container.js:166:24)
    at AtRule.append (/Users/username/projects/myproject/node_modules/postcss/lib/at-rule.js:13:18)
    at /Users/username/projects/myproject/node_modules/tailwindcss/jit/lib/collapseAdjacentRules.js:26:21
    at Root.each (/Users/username/projects/myproject/node_modules/postcss/lib/container.js:60:16)
    at /Users/username/projects/myproject/node_modules/tailwindcss/jit/lib/collapseAdjacentRules.js:10:10
    at LazyResult.runOnRoot (/Users/username/projects/myproject/node_modules/postcss/lib/lazy-result.js:303:16)
    at LazyResult.runAsync (/Users/username/projects/myproject/node_modules/postcss/lib/lazy-result.js:355:26)
    at LazyResult.async (/Users/username/projects/myproject/node_modules/postcss/lib/lazy-result.js:205:30)
    at LazyResult.then (/Users/username/projects/myproject/node_modules/postcss/lib/lazy-result.js:190:17)
    at /Users/username/projects/myproject/node_modules/webpack/lib/NormalModule.js:316:20
    at /Users/username/projects/myproject/node_modules/loader-runner/lib/LoaderRunner.js:367:11
    at /Users/username/projects/myproject/node_modules/loader-runner/lib/LoaderRunner.js:233:18
    at context.callback (/Users/username/projects/myproject/node_modules/loader-runner/lib/LoaderRunner.js:111:13)
    at Object.loader (/Users/username/projects/myproject/node_modules/postcss-loader/dist/index.js:104:7)

@lacolaco, I also tried to add a postinstall script you mentioned from the blog post, but it seems it's incompatible with the newest v2.1 as they merged JIT plugin directly into Tailwind.

I figured out what is the issue, but didn't figure out the cause.
Inside src/styles/styles.scss I have another partial imported as @import "global/fonts"; (its file is located here: src/styles/global/_fonts.scss). This files contains the next import of Google fonts:

@import url('https://fonts.googleapis.com/css2?family=Inter:wght@400;500;700&display=swap');

With this setup, I get this nasty error. If I just remove this import or move it to the main SCSS file (src/styles/styles.scss), I don't get the error.

Now, I'm not sure where to file the issue. Can anyone suggest what is the origin of this error; tailwindcss JIT (it only happens while running in this mode)? postcss-loader? postcss? mini-css-extract-plugin? Google font import itself?

vltansky · 2021-04-20T10:17:33Z

For the purge setting, it would be preferred if Tailwind itself provided a more fine-grained method to specify its production mode. Two potential options for this are a programmatic option when initializing the plugin or a targeted environment variable (e.g., TAILWIND_ENV/TAILWIND_MODE/etc.). The NODE_ENV environment variable has the potential to effect the behavior of every active dependency involved in the build system.
@clydin

Tailwind now has TAILWIND_MODE variable that should be set to watch or build.
Most of the workarounds enabling Tailwind JIT & watch is to set TAILWIND_MODE manually.

function guessProductionMode() {
  const argv = process.argv.join(' ').toLowerCase();
  const isProdEnv = process.env.NODE_ENV === 'production';
  return isProdEnv || [' build', ':build', 'ng b', '--prod'].some(command => argv.includes(command));
}

process.env.TAILWIND_MODE = guessProductionMode() ? 'build' : 'watch';

Would be really useful if Angular CLI would set this variable instead.

clydin · 2021-04-20T14:01:43Z

@vltansky Would the changes in #20574 be sufficient?

vltansky · 2021-04-20T14:10:00Z

Looks good to me

tylerthrash · 2021-05-07T20:07:03Z

@clydin thanks for adding that.

To help clarify for others, as of Angular 11.2.12 or "@angular-devkit/build-angular": "~0.1102.12" the following code will work for setting Tailwind purge to be enabled for building and off for serving ('watch'). Be sure to also have Tailwind v2.1 or greater installed.

module.exports = {
  purge: {
    enabled: process.env.TAILWIND_MODE === 'build',
    content: [
      './src/**/*.{html,scss,ts}'
    ]
  },
  theme: {
    extend: {},
  },
  variants: {},
  plugins: [],
};

alan-agius4 · 2021-06-22T08:31:20Z

Closing since the above has been addressed.

angular-automatic-lock-bot · 2021-07-23T08:03:12Z

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}

vltansky changed the title ~~Tailwind suuport~~ Tailwind support Feb 10, 2021

alan-agius4 added area: devkit/build-angular devkit/build-angular:browser labels Feb 10, 2021

ngbot bot modified the milestone: needsTriage Feb 10, 2021

vltansky mentioned this issue Feb 11, 2021

feat(@angular-devkit/build-angular): tailwindcss purge #20036

Closed

vltansky mentioned this issue Feb 16, 2021

docs: add Angular integration guide tailwindlabs/tailwindcss.com#759

Closed

vltansky added a commit to vltansky/postcss-ng-tailwind-in-components that referenced this issue Mar 4, 2021

fix: generate two rules instead of one with coma

b592cd2

angular/angular-cli#20015 (comment)

dgp1130 mentioned this issue Mar 11, 2021

Provide Angular build context to external tool configuration files #20253

Open

1 task

ganySA mentioned this issue May 10, 2021

Angular 12 RC 2 - Compilation is enormously slow and crashes on large build. #20713

Closed

14 tasks

alan-agius4 closed this as completed Jun 22, 2021

vltansky mentioned this issue Jun 23, 2021

add TAILWIND_ENV environment variable for better Angular support tailwindlabs/tailwindcss#4765

Closed

angular-automatic-lock-bot bot locked and limited conversation to collaborators Jul 23, 2021

Tailwind support #20015

Tailwind support #20015

Comments

vltansky commented Feb 10, 2021 • edited

dgp1130 commented Feb 11, 2021

vltansky commented Feb 11, 2021

clydin commented Feb 11, 2021 • edited

vltansky commented Feb 11, 2021

nartc commented Feb 14, 2021 • edited

beeman commented Feb 16, 2021

ahasall commented Feb 16, 2021

vltansky commented Feb 16, 2021

devpato commented Feb 17, 2021 • edited

eweap commented Mar 1, 2021

rnbrady commented Mar 4, 2021

clydin commented Mar 4, 2021

vltansky commented Mar 4, 2021

nartc commented Mar 4, 2021 • edited

ahasall commented Mar 4, 2021

nartc commented Mar 4, 2021

rnbrady commented Mar 4, 2021

clydin commented Mar 4, 2021

vltansky commented Mar 4, 2021

clydin commented Mar 4, 2021

dgp1130 commented Mar 11, 2021

zub0r commented Mar 16, 2021

dgp1130 commented Mar 18, 2021

adrian-goe commented Apr 2, 2021

lacolaco commented Apr 6, 2021

ahasall commented Apr 6, 2021

mightymatth commented Apr 6, 2021

nartc commented Apr 6, 2021

vltansky commented Apr 6, 2021

vltansky commented Apr 7, 2021

mightymatth commented Apr 19, 2021

vltansky commented Apr 20, 2021 • edited

clydin commented Apr 20, 2021

vltansky commented Apr 20, 2021

tylerthrash commented May 7, 2021

alan-agius4 commented Jun 22, 2021

angular-automatic-lock-bot bot commented Jul 23, 2021

vltansky commented Feb 10, 2021 •

edited

clydin commented Feb 11, 2021 •

edited

nartc commented Feb 14, 2021 •

edited

devpato commented Feb 17, 2021 •

edited

nartc commented Mar 4, 2021 •

edited

vltansky commented Apr 20, 2021 •

edited