How can the Laravel-Enso packages be tested sensibly?

[pschucker]

This is a question.

Prerequisites

• [x] Are you running the latest version?
• [x] Are you reporting to the correct repository? (enso is made of many specialized packages: https://github.com/laravel-enso)
• [x] Did you check the documentation?
• [x] Did you perform a cursory search?

Description

Laravel Enso consists of multiple specialized (Laravel) packages. For my project, I have to adjust some pieces of Enso and especially change some .vue components. I also want to extend it with further laravel packages, that have the same structure as the Enso ones. I wonder if someone could tell me, how to setup a development environment, such that these packages can be tested efficiently? Especially the .vue-components. When I see it correctly, you can only compile the JS-part of the application in the final Enso-repo, where the package.json with all the dependencies is located and where all .vue components of all packages come together. The .vue-components in packages likes the File/Role/Permission-Manager refer to relative paths, that only exists in the final project but not in the packages itself.

Don't you use a setup for your Enso packages, that allows you to run a Laravel-mix like ‘watch’/'hot'-Task, that automatically compiles the .vue files after every change and display the results in a browser. So that you don’t have to publish a new version of the Laravel package you are currently working on, update dependencies for the complete project, copy the modified assets files via the publish command and compile the complete Enso project, before you can see any changes?

If so, it would be great if someone could explain it.

Steps to Reproduce

Expected behavior

-

Actual behavior

-

[aocneanu]

Hi,

https://docs.laravel-enso.com/guide/getting-started.html

Step 8 is yarn hot and does what you're asking for.

If you are working on a new package, or upgrading an existing component the flow would be working on the local (published) component until you get it in the desired form and then overwriting it in the source package (vendor/laravel-enso/package) and commit a new version of the package.

[aocneanu]

Can we close this?

[pschucker]

Hi,

thanks for the response. I knew about yarn hot but the flow was not clear to me. I hoped that there exists a better way than copying changes back and forth which is quite cumbersome.

I think I will try around with including the packages via composer's symbolic path option and using unionfs folders for the resources instead of copying them. I think that might work.

[aocneanu]

Yes, there is a more straightforward approach, repos on npm for everything related to the frontend. We’ll get there in the future.