Upgrade to Vite / Vue 2.7

[davestewart]

Hey @rogden,

I started this before noticing #91 but luckily I had already decided to limit the upgrade to Vue 2.x so as to not mess with existing dependencies.

So this PR will give you Vite 🔥, but not force any Vue 3 upgrade 👀.

And when you want to upgrade to Vue 3, it should only be a couple of changes (see below)

Status

I have the main build running great with Vite, which can check out and run right now.

However, I noticed that the CLI export script is not happy with the mix of ES6 and CJS, so that will need some tweaking; either upgrading that module to ES6 / imports, or downgrading the tailwind.config.js file to CJS.

I'm not hugely experienced with tailwind (hence #97) and whether there are user constraints that would require config to remain at CJS, perhaps you can advise? I'm sure there is a way for Vite to import a CJS file, so I'm happy to investigate.

Also, seeing as #91 was ultimately rejected, are you happy for this PR to continue?

Future upgrade to Vue 3

Change:

• @vitejs/plugin-vue2 to @vitejs/plugin-vue
• vue version to ^3.0.0

[rogden]

@davestewart Thanks for this! I'll look over it this week but I'm definitely interested in the PR/update path to Vite and eventually Vue 3.

This PR is appealing because it is incremental. The other PR had some elements I was interested in but I never got around to taking the bits I needed.

One thing to note (perhaps obvious) is that the Koa server is what ultimately serves the compiled app (and parses the Tailwind config to server to the compiled app at the /config.json endpoint) when someone uses the package.

Only when developing locally does the Vue CLI (and Vite in this case) run to serve the UI of the app. The other PR removed Koa in favor of using Vite to serve the production app which I wasn't keen on doing.

[davestewart]

Yeah, and I think the confusion with what was serving the config file may have had something to do with my earlier ticket.

I think that can be solved with a little docs update though.

By the way, the window global for the config path; is that supposed to be in some way configurable at runtime?

I didn't see it get rewritten from anywhere.

[rogden]

It is replaced when the export CLI command is executed here: https://github.com/rogden/tailwind-config-viewer/blob/master/cli/export.js#L20

It takes creates a hash of the config file contents and uses that as the file name instead of config.json to get around caching.

[davestewart]

Hey, just checking if you had any time to look at this?

I have not, since then :)

[rogden]

@davestewart Hey. Was just testing it out locally. I just pushed a change to remove the dynamic importing of the section components. I don't know why I did that vs just importing them directly but by doing so I was able to remove some more code.

Regarding the export not working...it works if you use the tailwind.config.sample.js file for the -c option. It will work with the tailwind.config.js if the extension is changed to .mjs since it uses import statements. Either way, there isn't a need to update anything for that to work. I'll add a note to the docs about ESM and naming the tailwind config file correctly.