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.
Related
I'm trying to write a universal React.js application using TypeScript and if possible it would like to somehow annotate certain TypeScript files in such a way that a file is understood to be running inside a browser context or Node.js context explicitly. So that any attempt to use browser APIs from within Node.js environment would fail, and vice versa. How can I do that?
Right now the files reside in the same directory and maybe that the problem because I cannot have multiple tsconfig files but if that is the only solution I guess I have to do it that way.
Each project described by a tsconfig.json file has a single set of visible declarations; there's no way to have different declarations visible in different files in the same project. You can put a <reference> directive in a specific file, but the directive will affect the entire project. So to enforce what you want using the regular type checker, you'll need to use multiple tsconfig.json files. There may be other approaches such as using the tslint "ban" rule to ban all APIs from one environment in a specific file, but I doubt they will be practical.
We have a list of browsers we test our webapp in. I have a task to notify the user if his browser isn't supported or tested to work well with our app.
We have a browserslist configuration in the project and I'm looking for a way to test current browser against the list.
I tried browserlist-useragent but we can't compile it with webpack due to the fact it uses net, fs, tls and other native node modules we don't want to include in our bundle.
Is there any better way do avoid copying the list of supported browsers in many different places and just use browserlist configuration that already exists to detect if user uses supported one or not?
I'd consider using this "utility" package https://github.com/browserslist/browserslist-useragent-regexp in the project that uses browserslist, and then use the file generated by the script suggested by this package to then use anywhere else.
In reality, all you want is the regex in the generated file. This can be placed in any client or server code you need for browser detection. I've placed mine in some classic asp.
Also note that on a Windows PC, the instructions provided don't result in a file containing a RegEx. Instead, you'd need to run npx browserslist-useragent-regexp --allowHigherVersions to display a suitable RegEx on your console, and then add that where needed.
I have a question regarding the node app that I want to build.
Before starting on the development, I've written a clear document that splits up my app into different components:
Home
Search
User profile
Dashboard
etc...
Each of these modules may in turn consist of different submodules.
As every module in my app works quite independently (although there are common, reusable components), I decided to render the main page for each of the modules from the server using Express.
Each of the pages that I want to render is highly interactive in the field of DOM interaction and event driven view updates, so I want to go with Backbone for this (using push state for loading submodules dynamically for the nested url's), in combination with requirejs for asynchronous module loading.
The thing I wonder about is if it is okay to include a minified file for each of the pages that I render from the server with express. It seems that this causes quite some overhead, because for each module loaded all the libraries need to be included again (backbone, underscore, jquery, and others).
Is there a common solution to this problem, and will this (in your experience) cause unacceptable performance issues?
What we end up doing with a similar multi page app structure is we break the build to separate "common.js" file that contains all the shared modules, and "main-[module-name].js" files for page specific code, and load it with 2 separate script tags per page
I don't know that it has actual significant perf impact. I am guessing that not really, unless you have some large libraries in your project
Take a look at the multi page config example for requirejs
My $0.02
Can you compress all the web files like html, css, js, php without losing its readability?
I'm developing a dynamic website, but then client require me to update the site quite frequently, the problem is that whenever I make any changes to the website, I need to backup a .min version(to webhost) and the original files(for development).
The problem is that keeping two sets of files are quite tedious, and prone to error easily.....
Is there a better way like a javascript that will handle all the compress functions when upload to host and I can re-use the same files for developement?
Thanks in advance
First, let's separate compression and minification. I assume we are only talking about minification here (removing spaces etc.) not compression like gzip.
There's 2 common ways to serve minified css/js/etc.
Edit readable version, minify offline, upload the minified files.
Edit and upload readable files, but dynamically serve a minified version to users.
I agree #1 is more tedious and prone to error, if sometimes you are forced to make changes to the min version and forget to bring the changes back to your dev side.
There're a lot of ways to achieve #2. If you're using PHP I would suggest Minify (it not only minifies but joins and compresses your CSS/JS to reduce file requests as well). That way you can maintain 1 set of readable CSS/JS files on both your dev and production side, and let Minify take care of the rest.
This is coming from the idea of 3rd party libraries being in Script to discourage developers from customizing them. It would encourage them to write extensions to make it easier to take in a new version of either library.
You make a good point about other developers mistaking the durandal libraries for customizable files.
But, you are not required to keep durandal anywhere. The folder structure can be whatever your heart desires. Because durandal does not impose any folder structure.. it only has a recommeneded default setup. There are benifits to following its pattern.
By keeping durandal as part of your application root folder. It keeps all your amd javascript files together in one root folder. This way when you run the durandal optimizer it can scan every subfolder to compress/minify/uglify all your html/css/js into 1 file. This is a nice benifit because its a 1 click build of your entire application.
Also, its a nice seperation because its a good idea to keep your 3rd party non-amd JavaScript libraries in a separate folder structure this way if you use a bundler to compress all your third party libraries into a separate file. The browser can cache your application separate from the third-party libraries. Because the third-party libraries don't change very often, whereas your application will probably be changing frequently.
But durandal's conventions are all completely configurable and you can put durandal in any location you like.
This is a convention that Durandal has decided to use to help keep your customer client code organized in an App folder and away from the 3rd party scripts folder, which gets pretty messy pretty quickly. It does put require.js in the App folder because of the way it relies on require.js and its AMD pattern. require.js is used to help locate all modules and load them as needed (in your App folder).
Is there something specific that you need that this is preventing?