Adds configuration file update tool to CLI

[MattStypa]

Summery

Users can now easily update their v0 configuration file to v1 configuration format using the update command.

What else is in this?

• I have added the container property to the theme in the default configuration stub.
• Updated CLI commands to use consistent color scheme.
• Updated CLI commands to show paths in a nicer way.
• Changed the testing of the CLI commands. Tests will no longer fail if the configuration file exists.

What is NOT in this

The output is very verbose. In the future I want to:

• Ommit configuration that is equal to the default.
• Collapse colors and spacing like we currently do in the default configuration stub; if possible.

[adamwathan]

Haha sick! Man I was working on something like this the last two days, wish I had known you were looking at it too... I'll pull this down and play with it today or tomorrow, there was a bunch of stuff I wasn't sure how to solve that I'm curious if you were able to fix.

The main messy points for me were preserving any third-party plugins and dealing with any weird structuring, like splitting things out into extra variables or god forbid files.

[MattStypa]

It's possible that I missed something. This stuff is not easy. In a nutshell, I use real require to pull the configuration object in, which should resolve any "magic", users might have used. I briefly hijack the require method to swap old Tailwind dependencies like the default config and the container plugin with stand-ins.

[adamwathan]

I just tried to run it against the default config from 0.7.4 but am getting this result:

Here's the repo I was hacking around in in case you're curious, still a mess but whatever.

https://github.com/adamwathan/upgrade-config

[MattStypa]

Can you share your tailwind.js file? I pulled the one from https://github.com/adamwathan/upgrade-config but I am getting a different issue.

I assumed that all properties are required. The transform is very lenient and the validation rules can be relaxed quite a bit.

This could also be related to the Node version.

[MattStypa]

I removed backgroundPosition from the validator. This resolved the issue I was having. I am still unable to replicate the problem @adamwathan had.

Can you think of any other properties that may not be present in the config file users will try to update?

[adamwathan]

This is the file I was trying to update:

https://unpkg.com/[email protected]/defaultConfig.stub.js

Technically every key in the config file is optional although my current repo doesn't handle that gracefully either.

[MattStypa]

Ok. I replicated the issue.

This is caused by requiring a missing module.

  plugins: [
    require('./plugins/container')({
      // center: true,
      // padding: '1rem',
    }),
  ],

My guess is that you simply copied a stub over instead of using the init command. init should have replaced require('./plugins/container') with require('tailwindcss/plugins/container')

This configuration file probably does not work for building either.

I will refine this PR to handle missing keys in a more graceful way.

[adamwathan]

Ah yeah good catch, my mistake. That said that kind of points to the more challenging issue I was trying to solve yesterday, where someone may have third party plugin references:

plugins: [
  require('some-third-party-plugin')({ ... }),
]

The only way I could think to handle it is by treating the upgrade process more like string replacement than actual manipulation of the config object, since I'd want to preserve those require statements in the new config file. Tricky shit :/ I think the ultimate approach would to do it with babel but I don't know if I really want to go down that road, hah...

[MattStypa]

There might be a way to leverage what I am already doing for the container plugin. I think I can replace the external dependencies with placeholders and then swap them back in when generating the new config file.

Do you have any real-life examples of external plugins?

[MattStypa]

I am going to close this PR for now for a few reasons

1. It does not even work for external plugins
2. There are some issues that are very hard to solve
3. There are some minor CLI enhancements that don't need to be blocked for the reasons above

[adamwathan]

I'll put together a little demo project today that includes some third party plugins and multiple different config files as test inputs and we can keep hacking on this. I've decided I'm going to push the final v1.0 release back a few more weeks so we can really polish the docs before opening the floodgates so we have a bit of time 👍