Vite 4.0 about peat HOT 13 CLOSED

Yea I'm an idiot that doesn't know how to read. 😅

Got it setup and working in dev and production mode, and with multiple Vue apps.

Thanks for your help! This is a great project.

from peat.

Hello. Yes, I am planning the update and will work on it shortly.

The current version of Peat most probably is already compatible with Vite 4, as I have not found any mention of breaking changes to the manifest file Vite produces, which is what Peat hooks into. You might give it a try.

from peat.

From what I can tell, only the default server port for development server has changed from 3000 to 5173 since Vite v3. You should be good to go and use this tool for your integration @compilekaiten.

from peat.

Hey. I figured this would work fine, since not a lot has changed. But, I saw the ReadMe said 2.*, so I figured I'd ask.

I'll go ahead and test this out, and see if it fits my project.

Thanks!

from peat.

I have just updated the readme to mention support for v3 and v4. Let me know if you encounter any problems.

FYI: This tool is production ready, I'm using it on multiple projects, I just have not found time to include automated testing, that is the only reason it sits on 0.* versions.

Have a nice end of the year.

from peat.

I have just updated the readme to mention support for v3 and v4. Let me know if you encounter any problems.

FYI: This tool is production ready, I'm using it on multiple projects, I just have not found time to include automated testing, that is the only reason it sits on 0.* versions.

Have a nice end of the year.

Any chance you have a link to a project that utilizes this? Would be nice to see visually how this operates. I'm not sure I'm setting this up correctly 😅

from peat.

let me give you a helping hand.

first, you need to understand that all this tool does, is provide you with script tags to your jS modules and link tags for CSS files, which it reads from manifest.json generated by Vite in production/build or localhost dev server.

So you first need to configure Vite to

1. generate manifest file upon build
2. output JS entry file instead of HTML entry file (which it generates by default), usually main.js

Since you will be serving the JS/CSS assets from PHP, you do not want the static HTML.
For that you only need to <?php echo $locator->entry('src/main.js'); ?> in your PHP template.

To get the locator, you configure the bridge service

$bridgeService = new ViteBridge(
    manifestFile:  __DIR__.'/public/my-js-widget/manifest.json', // this must poin to the manifest file
    cacheFile: __DIR__. '/temp/vite.php',  // this may be any writable file location
    assetPath: 'my-js-widget', 
    devServerUrl: 'http://localhost:5173',
);

and

$locator = $bridgeService->makePassiveEntryLocator(false); // pass true here for development

As you can see, if you pass true above, the script and link tags willl point to your localhost where you should have the dev server running.

Let me know if you have problems with the PHP configration or you are unable to make Vite output the correct files for you.

from peat.

and nope, i dont have any open source project using this ... maybe I should create a a sandbox.

from peat.

So I think I've got it setup correctly. This is my project layout: https://prnt.sc/osOBORtxzqlj

• public_html is my web root and where I'm using the bridgeService and locator.
• the js folder houses my Vite/Vue3 TS project.

What I'm a bit confused on, is if I include the HTML tags in my index.php file like in the screenshot above, or just echo the locator?

I think a Sandbox example would be nice, especially for people like me that aren't as experienced.

Thanks

from peat.

I understand now.

You want to remove the echo part on line 15 (keep the assignment), and replace the lines 26-27 with just <?php echo $html; ?> to output the content there.
In development mode (what you have there now) it should print exactly the same content on those 2 lines. That is how you know it works correctly.
Once you pass false to $bridge->makePassiveEntryLocator(false), the printed tags will point to assets compiled by Rollup. That will be your next step.

P.S.
You are not echoing the locator, but the assets returned by the Locator::entry method (see ViteEntryAsset class).
The (string) type-cast will call the ViteEntryAsset::__toString method, which outputs HTML including the tags you need (for the given entrypoint)

from peat.

Maybe the documentation sux 🤷‍♂️

BTW I created a simpler approach with ViteHelper ... Wonder if that would have helped you start it up faster.

The helper would basically reduce your code to this for bundles:

<?php echo Dakujem\Peat\ViteHelper::extractAssets('src/main.ts','./vue/manifest.json','/vue'); ?>

and this for development server:

<?php echo Dakujem\Peat\ViteHelper::populateDevelopmentAssets('src/main.ts','http://localhost:5173'); ?>

But it does not use the PHP cache file and as such is a bit slower.

from peat.

Maybe the documentation sux 🤷‍♂️

BTW I created a simpler approach with ViteHelper ... Wonder if that would have helped you start it up faster.

The helper would basically reduce your code to this for bundles:

<?php echo Dakujem\Peat\ViteHelper::extractAssets('src/main.ts','./vue/manifest.json','/vue'); ?>

and this for development server:

<?php echo Dakujem\Peat\ViteHelper::populateDevelopmentAssets('src/main.ts','http://localhost:5173'); ?>

But it does not use the PHP cache file and as such is a bit slower.

I think this is a nice way to get up and running very quickly, especially if someone wants to just test it.

Utilizing the cache is a must though!

from peat.

Yes, that cache improves the performance a lot in production, especially with opcache and jit.

I included that ViteHelper in documentation for "configuration troubleshooting", that should get people on the right track faster.

See it here: https://github.com/dakujem/peat/tree/feat/friction-reducer#troubleshooting-configuration

from peat.