Leaderboard

Same place where we've always been, and where we're ultimately going to be with any dependency management solution, automated or manual: risk assessment. Any time we depend on third party dependencies we're making a choice to trust the vendors of said dependencies (and by extension anyone they trust, and also anyone who might have access to the "pipeline" in between us and those vendors). Whether the benefit is greater than the risk is what matters. (Sorry for going a bit philosophical with this ?) As for Composer vs. npm, my opinion is that the situation with Composer is slightly less problematic, simply due to the ecosystem. I don't have numbers to back this, so please take it with a grain of salt, but in my experience relying on numerous interconnected dependencies is more common for npm projects. ProcessWire modules, for an example, tend to have relatively few dependencies, which can be a good thing (in this particular context). One solution, mentioned in that Reddit discussion as well, is roave/security-advisories. I would recommend adding it to your setups, just in case. It's a super simple package that defines a list of "conflicts", each of those being a package + version with known vulnerabilities. When running composer install or composer update, these conflicts crash the process. This may well be the only "positive use case" for conflicts I've come across ? It's not a fool proof solution, but a good start — and pretty much a no-brainer, in my opinion. Another thing that can help is private packagist, which provides automated security audits, alerts, and more. Private packagist is not free, but for commercial users it's definitely something to consider (and not just for the security features).

A couple of potential things - I think getByIDs would be more performant. And also, if you have JSON in the meta, then using JSON_VALUE might be helpful.

Only option I know is plain SQL: <?php // populate test value $pages->get(1)->meta('foo', 'foo'); // find pages $result = $database->query("SELECT source_id FROM pages_meta WHERE name = 'foo' and data = '\"foo\"'"); $ids = implode("|", $result->fetchAll(\PDO::FETCH_COLUMN, 0)); db($pages->find("id=$ids")); If you use this with user input be sure to properly sanitize the data and maybe use prepared statements!

Oh...kay... now I get it. Sure this could happen in some way in or with Composer as well. The r/thread is a nice read. This whole scenario was always the reason why I rarely used and use NPM or Composer - it's so often a big blackbox.

I just released a new extension module AppApiPage (waits for approval), which handles the initial steps from my post above completely automatic. You install AppApi and AppApiPage. That makes the /api/page route available and you only have to add the code on top of your template php to add a custom JSON output to your pages. <?php // Check if AppApi is available: if (wire('modules')->isInstalled('AppApi')) { $module = $this->wire('modules')->get('AppApi'); // Check if page was called via AppApi if($module->isApiCall()){ // Output id & name of current page $output = [ 'id' => wire('page')->id, 'name' => wire('page')->name ]; // sendResponse will automatically convert $output to a JSON-string: AppApi::sendResponse(200, $output); } } // Here continue with your HTML-output logic... I hope that this makes it even simpler to add a full-blown JSON api to new and existing pages.

If you are interested I can take the time to publish a draft of a profile which you could use as starting point, and IMO it's better and easily than other solution that I could have tested. Basically it use a modified version of InertiaAdapter made by @clsource and let you code your app inside ProcessWire's template and using pages for everything fetched dynamicaly and internally, as JSON. You can see it "in action" in this example url: https://blog.sekretservices.com/ (Do not take care of the issue while refreshing the blog post due to hanna codes, it's an old version) For example, from your template you build the page properties as a simple PHP array, let's say I want to fetch the title of the page: $component = "Home/BlogPost"; $properties = [ // accessible from app components with $page.props 'name' => $page->name, 'title' => $page->title, 'subtitle' => $page->subtitle, 'content' => $page->body, 'author' => ucFirst($page->createdUser->fullname[0])."."." ".ucFirst($page->createdUser->surname), 'date_created' => $page->created, 'date_relative' => $datetime->relativeTimeStr($page->created) ]; Then from a component BlogPost.`{svelte, vue, react}` (or whatever) you can simply retrieve the page's props like: (Svelte example) <script> import {inertia, page} from '@inertiajs/inertia-svelte'; export const { title:title, body:body } = $page.props </script> <div class="blog-post"> <h1 class="font-sans mt-8 text-center font-bold">{@html title}</h1> <div>{@html body}</div> </div> Look at this sample, at the page's tree and the routes prop from the console : About the workflow, it's not really different from what you should be used to. You write your logic in template in PHP then write some HTML/JS in your component. Also, hot module replacement (HMR) is working ? A word about server side rendering (called SSR and which is needed to get best SEO results), it's working for React and VUE, still a WIP for Svelte ? Get a note of ?on every lighthouse performance. Bundled with ViteJS, powered by ProcessWire, I am glad to say that it's the best stack I have ever built and used ?? Edit: A small note, but the better one. You don't have to build your app again on every change on the backend, I mean for example when you add a new page, it's work out-of-the-box, you create and page, and it's available to your JS components. Edit2: To understand better, here we can achieve what you already used/saw with Laravel. Having a `src` folder with the JS things, another folder with the Laravel `app` and running artisan and some npm command. Here, in dev mode, you run `yarn dev` and you are ready. Simple as that.