Build system updates

[Niksac]

As discussed in the other MR, i put some work into loading all dependencies from the npm sources and reorganized the built system quite a bit.
The dist folder and especially the included "vendor" folder is not part of the repo anymore and all third party code is loaded and budled via npm and webpack.

Fonts and the file uploaded (filepond) are also loaded from there.

Package remarks

• Iconly is not available on npm but free to redistribute. Its still part of the repo.
• The bootstrap-datatables plugin was customized quite a bit, so I didnt load the BS5 version from npm.
• The simple-datatables plugin was also customized but I replicate those adaptions after table render now.
• SVG-loaders have been modified (fill color) so I had to include them as well

Extension vs page
Although most examples are being used on a single page only, some resources are loaded from folders called extension and some are loaded from pages.
I'd suggest that for the demo, we load page specific SCSS and JS only so the extensions resources folders would be moved into the pages folders.

RTL support
Because the RTL layout used a separate, modified stylesheet which is now gone with the dist folder, RTL is broken.
I dont really know rtlcss and dont know which changes were done to make rtl work.
There are some page specific adaptations as well.
I would suggest creating a separate RTL entry point which can load the (experimental) bootstrap5 rtl version and make some overwrites to the mazer styles.
Maybe @MahdiMajidzadeh can help us out here.

I'm creating this MR for discussion purposes - please don't merge right away.
Please try, if the build works on your end and if you notice something.

[zuramai]

I think the second one is better.

1. Flattening the structure of the scss folder. If we don't use subfolders there, we could set the resource root to "../../".

For the first one, this will create a messy scss structure and the development will be pain to see flattened files in one folder.

3. Accept that it's an absolute path as most people will run from a root domain and rebuilding with a different (absolute) path is possible.

I guess no one will use this template if it can't work in a sub-path. And it's important to create a demo in Github Pages, which the root project URL is in /mazer/.

2. Using copy for all resources. This means we would also need to overload or rewrite CSS in many cases which imho partly defeats the point of loading provided files where possible.

And this is the one that I guess is the best option. In the current main branch, we're using only the copy of the dependencies downloaded not from the npm. We can easily change this by copying the entire package to a folder in dist/.

In case to avoid the sass problem, we'll just use the copied .css files from the dist folder rather than linking the CSS files from node_modules in sass directly like you did before:

// The way to import from node_modules 
@import "~@icon/dripicons/dripicons.css";

Instead, we can do this:

// turn off the processCssUrls so Laravel Mix wouldn't change the URL we point to the dist folder.
mix.options({ 
  processCssUrls: false
})

// copy the deps to vendors folder
mix.copy("node_modules/apexcharts", "dist/assets/vendors/apexcharts")

And finally, we link the script to the src/*.html files as usual:

{% block js %}
<script src="assets/vendors/dayjs/dayjs.min.js"></script>
<script src="assets/vendors/apexcharts/apexcharts.js"></script>
<script src="assets/js/pages/ui-apexchart.js"></script>
{% endblock %}

What do you think?

[Niksac]

I think by copying over files, a lot of advantages of using a bundler are getting lost.
Also, I think when using a specific chart library or another component, that's displayed in the demo, devs would prefer to clearly see from the source how to install, import, and apply them as js modules instead of copying files over and having additional script or style embeds.

However, I think I found a good solution now.
Please take a look at my latest commit.

I was wrongly assuming we had to flatten the scss structure. Instead, we need to flatten the structure of the generated css structure which is much less of a pain.
Also, we don't really need to flatten it but only ensure the same file level depth of each generated css file.
Actually, this only required two small changes in the mix js file.
The result is that the main css is now loaded from a subfolder too (like page-specific css) which I think has a close-to-zero negative effect.

[Niksac]

Hi @zuramai
what do you think about the current version?

[zuramai]

Hi @Niksac,

That's a completely great improvement and we could release after this for version 2 of Mazer.

And there's one missing dependency, I guess you can add it to package.json file.
Module not found: Error: Can't resolve 'datatables.net' in '/mazer/src/assets/js/extensions'

[zuramai]

And we actually need the "dist" folder for them who want to directly use the build result. Is there any way to include the "dist" folder automatically on release? So it would be included in the zip release file. If there is not, I guess we could upload the zip manually to the releases.

[Niksac]

Hi @zuramai
I added datatables. My npm was not complaining about it missing, as it is implicitly installed with datatables.net-bs5 🤷.
But it doesn't hurt, so I added it.

Regarding the dist folder and releases:
This could be done with GitHub actions.
I usually use something like release-it. It automates a lot of things from increasing the version number to creating tags to creating the actual release on GitHub.

I created a branch on my fork and did a basic setup. This will bundle the files, zip them, and attach the dist.zip when releasing to GitHub.
That would be convenient enough for maintainers I think.

Warning:
Currently npm run development does not compile the nunjuck files. It works works mix watch and mix hot - that's why I never noticed.
It's probably a problem with laravel-mix-nunjucks - I'll have a look at it. Until then, run npm run watch before running the release command.

[zuramai]

can you make a pull request from your release-it-test branch?

After your two pull requests merged, I will release a RC version before it goes to V2.

[Niksac]

@zuramai
Because of the bug with laravel-mix-nunjucks I'd wait before merging the release-it stuff.
I suggest you make an "RC" branch for us to merge the build tools and later the release stuff.

Also, you should decide, if the lack of RTL is a show-stopper for a release.

[zuramai]

I have made the RC branch, check it out.

For RTL issue, it shouldn't be a problem for early v2, we can still add features gradually. We need this PR and release-it stuff to be merged because it changed the development environment much better.

[Niksac]

I figured out the problem with laravel-mix-nunjucks. It's a windows problem and works on POSIX systems.
I created an issue and I'm sure this will be fixed upstream sometime soon.

Maybe we add a notice for windows users.
I'll adapt this merge request later today.

[zuramai]

I don't know if there's an issue around the OS, but it's working on my both systems, Windows and Arch Linux.

[Niksac]

npm run development won't compile the nunjuck files at the moment (it works in watch mode though).

I'm working with the dev on solving it.

[Niksac]

Hi @zuramai
I've merged the release-it stuff into my build-system-updates branch and changed this MR to merge into your 2.0 branch.

I removed the broken RTL page from the demo and replaced it with a "coming soon" page with a notice about existing support in old versions.

While on it, I did quite some textual changes. There were spelling errors or unfitting text on several places.
Please take a look.

laravel-mix-nunjucks is still broken in the latest release, but the dev will probably fix it tomorrow based on his activity.

[zuramai]

Great! We can upgrade the laravel-mix-nunjucks soon after the dev released the version which the problem has already fixed.