-
-
Notifications
You must be signed in to change notification settings - Fork 190
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
Integrate Vite & Rework Mix #1141
Conversation
Couple of initial comments:
|
100% agree, makes sense.
Install isn't just installing packages, it's validating the configs are set and adding packages to workspaces, then adding deps if required, I kinda like how it is atm, although maybe it should be named something different.
Yes for theme, maybe for plugins, and maybe for somebody adding assets from a plugin to a theme (idk why but they could). All these edge cases are solved by just setting the same base that we pass when executing the command. Basically the php side needs to match up with the js web socket server. We could default to a guess, but it may cause more confusion when it fails than just setting a path and being done with it. |
Thanks for the feedback @jaxwilko.
That's cool by me. I just would like a rational and natural way for someone to "update" their dependencies - especially with the frequency of JS libraries and their dependencies being affected by security vulnerabilities. I suppose that
I've been thinking about this exact scenario for some time - pretty much since we introduced Mix. I think the easiest way we can move forward on this is that we have to consider that each plugin and theme is responsible for its own build and assets and that's it. The fact is, not everyone is going to write plugins and components that work nicely with every type of build used by themes, especially when our goal with the CMS side is that "people can use whatever front-end framework they want". As you said too, people can have the plugins (or at the very least, the components) inject assets into the theme when used. I still would argue that it would be most likely that the "entrypoint" to these assets would still reside in the theme if they built the plugins themselves. For third-party plugins, it's fair game for them to have their own build process and you simply use the compiled assets (or perhaps the build process in the theme could concatenate/minify these assets into the theme build). Either way, I think they're both out of scope for the So I wonder if we can just simplify the Thoughts on this? |
I don't think vite will play ball, unless we only enable vite for themes and not plugins (which was my first thought before I was able to get plugins working too). By all means have a play with it, but I think currently just adding the base covers all possible situations with the most flexibility. |
Docs PR: wintercms/docs#200 |
Co-authored-by: Luke Towers <luke@luketowers.ca>
Just waiting for @bennothommo to weigh in on the remaining two items (package.json being excluded from the source export & moving the PackageJson class into either the Storm Parse package or the Laravel Config Writer package). |
@jaxwilko @bennothommo are there any remaining items before we can merge this? |
Not that I'm aware of. |
This PR implements support for Vite side by side with Mix. All exsiting Mix functionality has been retained, but all the commands have been abstracted to allow for re-use by Vite. This allows for full support of both compilers, at the same time.
Modified
mix:compile
,mix:watch
,mix:install
,mix:list
all now rely on abstractAsset*
commands and inherit 90% of the functionality to allow forVite*
commands to reuse the same code.mix:run
&mix:update
- these were used for interacting withnpm
via the Winter CLI, these have been renamed to refelect their function tonpm:run
&npm:update
. Alias have been set to refer back to their previous names incase anybody is using them in scripts.New
vite:compile
- shares args withmix:compile
calledvite build
under the hoodvite:watch
- shares args withmix:watch
calledvite
under the hood (defaults to "watching")vite:install
- shares args withmix:install
allows for configuringpackage.json
workspaces and installing required global packagesvite:list
- shares args withmix:list
vite:config
- new allows for setting up stub filesmix:config
- new allows for setting up stub filesSystem\Classes\PackageJson
- Now provides a consistant interface for modifyingpackage.json
files rather than using json_encode/json_decode everywherevite()
has been added, this works similarly to Laravel's@vite()
in blade, however it required the base path to also be passed.vite:watch
,vite:compile
,mix:watch
&mix:compile
now support--disable-tty
which passes output back to the SymfonyProcess
allowing for capture by callers (useful in testing).Docs
Add a
vite.config.js
file to whatever package (plugin, theme, module) you want, then expect the same behaviour as you would with themix:*
commands, but withvite:*
instead. This can be done for you via thevite:config
command.When using Vite, to load your assets in your markup you need to use the new
vite()
function. It takes 2 arguments, an array of entry points, and the package name for where the assets are loaded from.This should end up looking like:
Vite can also be used in the backend:
TODO
*:config
TestCases