Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for TypeScript configuration files #7327

Closed
wants to merge 1 commit into from
Closed

Add support for TypeScript configuration files #7327

wants to merge 1 commit into from

Conversation

innocenzi
Copy link
Contributor

@innocenzi innocenzi commented Feb 4, 2022

This PR adds support for loading TypeScript configuration files.

// tailwind.config.ts
import { defineConfig } from 'tailwindcss'

export default defineConfig({
	content: [
		'./resources/views/entries/**/*.blade.php',
		'./resources/views/scripts/**/*.ts',
		'./resources/views/**/*.vue',
	],

	plugins: [
		require('@tailwindcss/forms'),
	],
})

Why?

Personally, it's basically my only pet peeve with Tailwind CSS: to be forced to use a .js config file and not to have auto-completion on the config object.

In the front-end ecosystem, especially on the Vite side, it's common to have xxx.config.ts files. They all provide types, so IDEs can provide auto-completion and we don't have to go back and forth to the documentation. It's also usual to have a defineConfig wrapper function to provide these types.

Examples of this are Vite, Vitest, Vue, Nuxt, Unbuild, Tsup, Windi...

Implementation notes

I went safe with the implementation by relying on a tool specifically made for this; unconfig. It itself relies on jiti (which I recommend checking out).

I would understand if you don't want to have a dependency here, but that was the easiest and most reliable option for me to implement this because I'm not familiar with the codebase.

A side-effect of using unconfig is that it handles multiple configuration files, so ts, mts, cts, and json are supported too.

That being said detective is not used for them and the config won't be invalidated when its dependencies are updated.

This is most likely fixable by I wanted to keep the PR understandable.

Advantages

  • Consistent configuration files in modern projects (*.config.ts)
  • Blessed with types and autocompletion
  • unconfig is made with interoperability in mind, so the VSC extension can use it too

This PR is a draft because, while it's working, it can be improved:

  • To invalidate the config when it changes (should be implementable easily)
  • To invalidate the config on dependency updates (need to get the transpiled TS config for that)
  • To add types, I didn't add them yet since I was not sure if you were going to consider the PR and it was a bit of work Add TypeScript types for the tailwind.config.js file #7891
  • Ensure everything works with the promises I had to introduce (lightly)

Whether this specific PR is going to be merged or not, please consider supporting TypeScript configs. I'm sure you are aware how it improves DX. 🙏

Related:

@innocenzi innocenzi marked this pull request as draft February 4, 2022 16:35
@hanneswidrig
Copy link

hanneswidrig commented Mar 11, 2022

This would be wonderful, any status update?

@innocenzi
Copy link
Contributor Author

This would wonderful, any status update?

I'm waiting for the team's approval before working further on this :)

@sasial-dev
Copy link

Is this PR impacted by #7891?

@innocenzi
Copy link
Contributor Author

Is this PR impacted by #7891?

Yes, very positively so; my PR doesn't bring types, it just supports .ts config files. The PR you linked added those types, so this is a big win :)

@sasial-dev
Copy link

Just letting you know (not sure if you were following the PR!) that #7891 has been merged :)

@mikestecker
Copy link

mikestecker commented Mar 31, 2022

Would love this! Any update from the Tailwind team @innocenzi ? I just updated all my postcss.config.js --> postcss.config.ts

@innocenzi
Copy link
Contributor Author

No update and it's unlikely we're gonna get any soon, I know they want to offer .ts config files, but if you read Adam's comment on the PR linked in the previous comment, you'll see they apparently have issues with the rest of the ecosystem.

Personally I believe the transpilation approach of this PR will solve the issue, but at least we have 1st party typings now, so let's let them take their time 👍

@bradenmitchell
Copy link

bradenmitchell commented Jun 28, 2022

As a work around, if you're using tailwindcss as a postcss plugin, you can explicitly set the path to the config file with a .ts extension. Make sure you have ts-node installed and module in tsconfig.json is set to commonjs or provide an override specifically for ts-node.

In postcss.config.ts

import tailwindcss from 'tailwindcss';

export default {
  plugins: {
    tailwindcss: { config: 'tailwind.config.ts' }
  }
}

Note: This does not work if you setup postcss from within the postcss-loader in webpack. Tailwind does not appear to honour any options passed when setup in this manner.

In theory you should also be able to set the config file to a .ts using the tailwind cli, but I have not tried this.

@thecrypticace
Copy link
Contributor

(you'll notice this is very similar response to the ESM config PR — since the reasons for closing are pretty much the same I thought I'd save myself some time)

Hey! So this has been open as a draft for a while now and I'm looking through issues. Looking into this we'd need to make a handful things async (some of which you have done) but this will definitely break intellisense with the way it's currently implemented. Many things there are assumed to be entirely synchronous. We definitely would like to have ESM+TypeScript support (I would love it personally too — I'm a super big fan of TypeScript in general) for config files but it can't happen in v3.1. The other thing is that getModuleDependencies would need to be able to track ESM imports/exports in addition to requires. This is further complicated by the fact that, in ESM, you can create your own require function using createRequire. Detecting config changes is simple enough but tracking ESM dependencies could be significantly more involved. I'm not sure if this will be something we want to look at in v3.2 or for a v4.0 in the future.

Given that this would be a non-trivial time sink for Tailwind CSS, Intellisense, and possibly the prettier plugin, we would need to be sure we could support and update all of those at the same time. Neither I nor the rest of the team have the time to do this properly right now so I'm gonna close this. I really appreciate your work on this and will absolutely reference and credit it in the future when we have a chance to think through this and implement it in a way that we feel comfortable with shipping.

It's very likely that when we eventually do ship ESM support we'll add support for typescript files alongside it should it work out to be a fairly simple to maintain addition.

Really do appreciate your time on this though! ✨

@innocenzi innocenzi deleted the feat/unconfig branch August 3, 2022 11:10
@innocenzi
Copy link
Contributor Author

@thecrypticace I understand, all of this makes sense - thanks, and I look forward to ESM support in the future. 🙏

@xiaohaoo
Copy link

期待添加ts的支持

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants