Please help
What is the best way in a Vite based Application to split the application codebase and it's configuration (the Application not the Vite) so that both could be independently
built
delivered
I can see two options myself still stuck with the implementation
Chunks splitting
I've tried extract path/to/appConfig.ts to a separate chunk
This worked but with two cons
I cant figure out how to run an individual build command for a specific chunk (eg just for a config only) without spend time for the rest ones
Whenever the appConfig.ts content changes the chunk hashes changes for all the existing chunks regardless correspondent content were kept stable
Lib splitting
I have just an idea to setup two different vite projects for App it self and for a Config as a library. Still I can't understand.
Should this be resolved with two individual vite.configs for that purpose?
This would be good for individual build but how would both the bundles be integrated in the same index.html that case?
So what the direction is the better one to evolve? Or maybe is there any more appropriate solution for this?
Thanks
Related
I seem to be unable to configure two entry points for my #nrwl/esbuild:esbuild target. I need to create two bundles. Is this possible?
I need to output two .cjs files, since I am using threads in nodejs and it seems that node isn’t happy for the main and worker thread modules to be in the same file.
The documentation is sketchy 😇 and I can't get the options on the ESBuild site to work in the project.json
I'm trying to develop a first Web Component using the Polymer Framework: https://polymer-library.polymer-project.org/3.0/docs/devguide/feature-overview
At the end, I want to produce a Web Component which will be distributed into several Web Application.
It's not clear yet for me how I can package such a Component.
Of course I can provide a copy of all the required Javascript files and ask people to put them at the right place, etc ... But at best, I would like to compact everything in a single JS file, so that the final user of my component just had to include one script, and need to deal with one single JS file.
Is there a way to build such file? Or what is the philosophy when distributing such components?
I am not really sure what you mean by distributing. Most components are currently published on https://www.npmjs.com/. npm publish basically creates a zip file and makes it easily installable for everyone.
I want to serve different vue pages from server by different routes. For now I'm using only one route (/static) to serve vue files for one "page" that contains vue-router.
I can't go one like this because the application should use cookies to verify access rights to different pages.
How can I accomplish this without using browser cache ?
Multi-Page apps are now supported very well with vue-cli v3:
https://cli.vuejs.org/guide/html-and-static-assets.html#building-a-multi-page-app
Found the solution for me. Unfortunately not a build in one. I just ran build process for two different builds with two different webpack configs which in their turn have different entry and output properties. Just in case someones find this helpful.
I see a barebone.jsp file created (I guess by the MinifierFilter) as well as for deploying compressed and cached js. I want to separate development and production cases, and as for development, I just don't want Liferay not only to cache produced javascript file, I don't want to have this generated instance at all.
To be more precise, I want all javascript files to be concatenated on the fly. I always want to have an opportunity to edit any statics files at development and to see results as soon as possible.
What is the easiest way to implement it?
include the settings from portal-developer.properties in your portal-ext.properties. This disables minifiers, caching etc. and you can develop without the problems mentioned. You don't want this setting in production though, as all files will be loaded individually.
(Edit: It might be advisable to include my comment from below in the answer):
You find this file in webapps/ROOT/WEB-INF/classes
All the *.fast.load parameters are for the various minifiers (css, js), but typically you want all of the parameters named in there.
I am currently working on a project that is using Dojo as the js framework. Its a rather rich ui and as such is using (and thus loading) a lot of different .js files for the dojo plug-ins
When run on an apache server running on a mac, the files (all around 1k) are served very quickly (1 or 2 ms) and the page loads pretty fast (<5 seconds)
When run on IIS on Win 7, the files are served at an unbelievably slow rate (150ms - 1s), thus causing the page to take up to 3 minutes to load.
I have searched the internet to try to find a solution and have come up empty.
Anyone have any ideas?
Why not let Google serve the Dojo files for you?
The AJAX Libraries API is a content
distribution network and loading
architecture for the most popular,
open source JavaScript libraries. By
using the google.load() method, your
application has high speed, globally
available access to a growing list of
the most popular, open source
JavaScript libraries.
What you need to do is build an optimized version of your code. That way you will have far fewer hits to your server (but I guess they'll still be slow, until you discover the iis problem) Dojo runs out of the box as individual files which is great for development, but without running the build scripts to concatenate all these files together, the experience is poor. The CDN does build profiles for dojo base and certain profiles, like dijit.dijit. Doing a dojo.require on these profiles in addition to the individual requires would enable this after running a build. You would need to do create layers for your code as well. The build scripts can also concatenate css and inline template files, remove comments and whitespace, etc.
Have you actually tried measuring the load times on the intended target production server?
If you're just testing this on local development environments (or in development/test VM's) then I think you're comparing apples with oranges (pardon the pun :) ).