'import {ComponentHere} from "angular2"', this one hits the server with so may calls for getting all the required file. Is there any way to decrease the number of calls to server?
//localhost:9739/node_modules/#angular/common/src/directives/core_directives.js.
//localhost:9739/node_modules/#angular/common/src/pipes/uppercase_pipe.js".
//localhost:9739/node_modules/#angular/common/src/forms/directives/control_container.js".
etc..
Consider using a WebPack (https://angular.io/docs/ts/latest/guide/webpack.html) it normally will decreased the number of files sended to client (but they will be obviously bigger)
You can use "SystemJS Builder" (https://github.com/systemjs/builder) and integrate it into something like Gulp to make it part of your build process for bundles. You give it an entry point (your app) and it then looks at your dependency tree to build your bundle(s).
When your bundle is used, systemjs will import from your bundle instead of every little js file. When I tested with angular2, I had over 700 files downloaded in DEV and only 35 in PROD when using the bundle.
Related
I've been using the Serverless framework to deploy my Express application. I used their Express starter template but since I've added code, when I try to deploy it says: Your code size must be less than 200MB. Try using Webpack, Parcel, or AWS Lambda layers to reduce your code size.
I've looked everywhere for a way to use Webpack to reduce my code size but have had no luck.
How can I use Webpack to make my code smaller than 200MB? Again, outside of more endpoints, my code is identical to this: https://github.com/serverless-components/express/tree/master/templates/express-starter
There are some options possible.
check if whats needs to be ignored(PACKAGES) is really ignored.
maybe you installed some packages that are taking too much space.
that's the main reasons for something like that.
Let me add also some points.
as #Ethanolle pointed - clean up your npm dependencies.
Include only used dependencies in your lambda build.
Take advantage of using npm devDependencies.
Consider using the webpack for creating your bundle - serverless-webpack plugin
As an alternative for webpack you may get the benefit of using the more precise configuration of Serverless how to manage what to exclude/include in a bundle
I am attempting to load a file from a remote URL during build to be WebPacked. This file is an MDX file and I am using the MDX vue-loader to load this file for use within the Vue application.
The system I am deploying is tenanted with a headless CMS powering some pages across the system. I would like to explore the possibilities of loading the MDX files at build time from a remote URL.
I have placed the MDX files on GitHub Pages with the remote URL passed in as an environment variable at build time.
The result is something like this (the idea here is that I can swap the domain during build to satisfy the tenanted site requirement):
import('https://somedomain.com/content/home.mdx');
This fails with your typical error during build of:
dependencies not found please install them using npm --save https://somedomain.com/content/home.mdx
I can WebPack ignore this import which allows it to build but then it fails to load in the browser as browsers will only load external modules with a MIME type of JS. Not to mention the fact that this hasn't been through the MDX loader so I suspect even if I could get the browser to load it the file would not have been parsed into something usable.
I realise I could copy these files in during the build stage from the remote but I was hopeful that there might be a way to either allow the browser to pull this remote file or WebPack to download this remote file and pack it into the output.
Does anyone have any ideas if this might be possible? Many thanks in advance.
As MDX needs pre-processing during build I think integration with Webpack is the only way.
You can try the SaveRemoteFilePlugin webpack plugin which allows you to download the file from remote to local file system. But maybe it's not what you want as it seems pushing downloaded files directly into dist folder without passing it through rest of the Webpack pipeline...
So probably better option is val-loader which allows executing your own Node scripts during build - here you can find the example which does almost what you need - Fetching Remote data during build
I have developed a vue application and did run npm run build
After that I uploaded the content in the dist file to my webpage but it returned a blank page.
Since I did this for testing I uploaded it to a folder in my public_html/mypage.com/vueapplication To get all the paths right I added a vue.config.js with this content:
// vue.config.js
module.exports = {
publicPath: '/vueapplication/'
}
The application now works but I wounder however:
how do I best publish/upload the application to my site? Just by simply dragging the content inte the right folder?
how can I best maintain my site? Do I need to build again and upload, overwriting my files when everytime I make an update on my site?
And what is the difference between build and deploy your application?
Drag and dropping your code should work. But as your app grows you may want to look into automating this. For instance if you use an S3 bucket you can use the aws cli to automate the upload.
Yes, you should overwrite your deploy folder(s). You need to also take care of deploying different binary files, that have the same name. An example is if you have a global css file (main.css for instance). The file will probably change content between deployments, but keep the same name. Browsers may cache the file so users that downloaded older versions of the file will not use the new one. There are different techniques to handle this, but if you use webpack, it uses cache busting techniques and you should be fine.
Build is the process of transforming source code into an artifact(s). Exactly what this means differs from language to language, platform to platform. In the vuejs world this usually means a couple of js files, a couple of css files and some assets.
Deploying means taking the output of a build and making it available to your users. Again this differs from project to project. In the vuejs world this usually means taking the artifacts from the build and uploading them to an http enabled web server.
Our release bundles are kinda huge (~50MB) and the clients take approx. 1-2 mins to download the update from codepush.
We're mostly just updating the js bundles, is there a way to just delta update the js bundle without re-downloading all image assets?
I've read from here that the server performs files diff, but it doesn't seem to work on my case: Logging RemotePackage.packageSize from checkForUpdate on clients shows the exact size of JS bundle + image assets, despite the fact that I've only changed the JS code.
Is there something I can do about this?
The CodePush backend should only serve the full contents up to the point it finishes creating a diff zip. On the backend your package is downloaded, extracted and analyzed for files that are different. Any new/updated/removed files are reconciled, put into another zip and shipped back up to the backend so users get served that instead of the original one you release. If you are seeing the full download, it's either because the backend is still working to process the diffs or there are differences inside your bundle.
I would try to do a release, wait 10 minutes and check to see if it is still downloading the full bundle. If it does, it'd be best to contact support for a deeper dive. As far as I can tell bundle's are processing correctly with next to no errors and running a quick test myself produced the correct results for me.
Is it possible to use Dojo build without the need to modify JavaScript files?
The article dgrid and Dojo Nano Build provides the instruction to create the build, but it requires adding the following line into JavaScript file, which initializes the application:
require(['dgrid/dgrid'], function () {
(replacing 'dgrid/dgrid' with your build module name).
However, it is very problematic when using build for own modules, because, of course, in development mode the require with own layer can't be included, otherwise the modifications made to own modules wouldn't be visible. But in production mode this line must be added.
So either you must modify the file manually before production build, or write a script that would modify the file during the build. Both are very error-prone.
Is there a better way to achieve that result? Is it possible for Dojo to recognize that the build is provided and should be used, instead of loading each module separately?
The following line of code can be included in both development and production modes.
require(['dgrid/dgrid'], function () {
I describe the reasons why in my answer here.
What you need to do is configure Dojo differently based on what environment.
In a blog post that I wrote, I describe this in more detail. The following summarizes the post:
I create three modes: Production, Uncompressed, and Development.
Development
When developing code, I will have the js source linked into the web server and the Development mode will point to the dojo.js file and the raw css file(s). The browser will load modules that I need using xhr. And I point to the top level css files which import other css files. The result is that a lot of requests will be made to the server and the loading of the page will be noticeably slow. The benefit is that you can see development changes without having to do a full build.
Production
Production mode points the main dojo file at the dojo.js that is built using the build tool. I also create <script> elements for the other layers that are needed in the page. I point the css to the built css files which the build tool has inlined the imported css. The page loads quickly, but it is difficult to debug
Uncompressed
Similar to production, but I point to the .uncompressed.js files. Production and Uncompressed are available in the released version of our software. I use uncompressed when trying to troubleshoot an issue in a production environment. The value of this mode is dwindling as the developer tools are better supporting compressed javascript (ie source maps, etc.)
Server side
The default mode is Production, but I use a query parameter to switch modes. I also store the current mode in the session, so that I only have to set the mode once to change it. Subsequent pages will run in the changed mode, until I change it back.
Here is a java implementation of this code.