What is the optimal way of packaging view templates for production use?
I have a number of .stache files. In development they are loaded synchronously with can.view(). In production i want to avoid multiple HTTP requests.
What is the right way to do it? Should i bundle them as single html file or single js file? Which format does StealJS use?
This is what I created can-compile for. For example
can-compile **/*.stache --out views.combined.js --can 2.1.0
Compiles all Stache files in the current folder and all subfolders into views.combined.js.
If you use Steal and the latest steal-tools (which is currently pending a release) and you import your modules e.g. using ES6 with
import template from 'my/template.stache!';
The view will be built into the production bundle automatically (and also loaded asynchronously in development).
Related
I am using 'animate.css' as a npm package. to use it I specify import 'animate.css' during development. But in production it says to include 'animate.min.css'. How to specify to parceljs to pick the animate.min.css during production build.
or would import animate.css would be able to resolve to right animate.css in development build and animate.min.css in production build. how does the resolver know to pick right file as the main file is specified as animate.css in the package.json
But the there is "Files" property in package.json ...not sure if it can help.
The high-level answer is that parcel automatically minifies and optimizes css files, so you don't need to do anything special to make sure that your production build is as small as possible.
If you want to understand in detail how parcel handles this particular package, read on.
Parcel generally follows node resolution conventions to figure out which files to actually import when you reference a package name.
In this case, the import "animate.css" will tell parcel to go looking in the nearest node_modules folder for a for a subfolder called animate.css. It finds it, and then looks for the package.json file at the root. In this case, the package.json has a main field that points to a file called animate.css (e.g. the un-minified version).
Parcel will use that file as the basis for development and production builds. When you run parcel in development, it leaves this file untouched. When you run parcel build it will process this (unminified) file through cssnano so the build output is minified.
So the interesting fact is that even though there is another file called node_modules/animate/animate.min.css living there, Parcel is able to achieve the desired behavior without touching it. The publishers of animate.css included it for other folks that aren't using a bundler that's as awesome as parcel - you can safely ignore it.
I'm currently developing a react application using jspm/systemjs.
I've been looking for a way to bundle assets inside of an bundle-sfx (build) file.
I have some images, fonts and potentially svg to add into my application. Currently the build file link those by urls into my sources.
But my goal is to be able to provide a single file to load in the html, which also bundle those assets; or at least package all those assets into a common folder from which I could serve as is.
For now I'm using systemjs/plugin-css, which concatenates all the css into a minified file.
I've looked at those plugins: vuzonp/systemjs-plugin-svg, systemjs/plugin-image, and systemjs/system-font.
But from what i read from that thread, it is not easily doable nor even possible at the moment.
Does anyone know how to do that, or could point me at the right direction ?
Does a plugin exist which would handle assets as undiscriminated files ?
Do I have to process each kind (mime-type) of file differently ?
If i've built a web app using code igniter, what's the proper way to deploy it? Should my install only include my files, or do I also package all the codeigniter code with it?
I'm just entering into the world of open source so I'm not so sure what protocol is.
Thanks.
This is a good question and I've seen it done both ways. There's definitely reasons Not to include the CI files. Like any potential in the future license changes. And it seems like with the projects that are shared by more experienced developers that is how they do it.
Because if you are sharing your project for other CI developers, then the reality is they will not use the copy of CI you include - they will fold your files into their version of CI. So including JUST the files needed for your app - actually makes much it easier. Its certainly what I would prefer. Just keep the standard application folder structure: config controllers models etc. but only include the folders that you have files for. And make it clear what version of CI you have tested it on. If you can say it will work on the release version (not the beta) then people on PHP 5.2 will know they can use it.
Of course you need to include all the CodeIgniter files, or else how would it run?
Most people tend to rename the application and system files and place them outside of the web root for security reasons. "After moving them, open your main index.php file and set the $system_folder and $application_folder variables, preferably with a full path, e.g. '/www/MyUser/system'".
I'm interested in making a smart package for the excellent three.js 3D library. It basically consists of hundreds of different JavaScript files - only several of which might be used for a simple application.
AFAIK, a smart package pushes it's JavaScript files to the client using the add_files method within the Package.on_use callback. If I was to bundle this entire library in a smart package is there any way for the client to specify what components it needs for any given project, or would I basically have to setup a separate smart package for every possible permutation of required components?
Well neither Meteorite nor the smart package API would directly support this AFAIK.
Here's three options:
If this is for other users to use, you could have a page somewhere that assembles a package for the users (Check out what Boost does on their website).
Just don't use a smart package. Put all the JavaScript files in your public directory and use jquery to download them individually.
You could split up the three.js project into many smart packages, put a dummy package in the packages directory and use the api.use(...) function to include each component you need.
Just keep in mind, three.js is already on atmosphere, and if the following thought crossed your mind, you should avoid putting hundreds of tiny inter-related subpackages on atmosphere.
And technically add_files is to add files to put in a bundle before running a server or deploying, it doesn't directly send files to the client.
I want a custom directory structure for my Content in my MVC project for example:
\Content
--\js
--\css
--\img
Is it possible to tell a NuGet package to install scripts in the Content\js folder? For example the jQuery package so that the jquery-1.6.js file is installed in the Content\js folder?
A workaround is to use the Nuget Package Explorer and download the package you want into that. You can then edit the folders within the package using Package Explorer to suit your taste and save it into your own Nuget repository. This can be a file system folder or you can get more sophisticated here: Hosting Your Own NuGet Feeds.
Of course this means that you have to keep the packages in your private repository up to date. Clearly if you have a lot of packages to deal with this could become a problem. However it seems quite likely that a future release of Nuget will deal with the issue of local feeds because it's an issue for companies that 'restrict which third-party libraries their developers may use' as mentioned in the Hosting your own NuGet feeds reference above.
I believe the answer to that is "No." There are, however, some references to be able to set the root folder NuGet installs things into: http://nuget.codeplex.com/workitem/215 (see the comments)
How jQuery gets installed is determined by the package producer, which is the jQuery team in your case.
Where the jQuery package gets installed is up to you.
However, the where can only be adjusted in terms of the location of the installed package ($(SolutionDir)\packages folder is the default), and the target project where you install it into. From then on, the package producer takes over and decides where each piece of the package content ends up.
There are some good conventions for ASP.NET MVC, such as a Content folder, a Scripts folder, an App_Start folder (for WebActivator), etc. Think about the risks and extra effort involved of trying to move away from these conventions. Do they outweigh the benefits?
Now if you really want to use your own conventions, you could create your own package with your desired content structure and put the jQuery scripts where you want them in the consuming projects.
This means you would be using your own package with that specific version of jQuery. You just have to be careful to respect the licensing policy of the original package, and not to break any specific installation steps or requirements from the original package, which is fairly easy to do if you manually start changing package structure.
The answer to this is "no" because the "Content" folder is one of the Nuget's convention folders. However, if you rename your Content folder to, for instance, public and then have Nuget pack your public/js folder then when you bring the package in it will extract the files to the public/js folder.
Since I started to use Nuget I switched to using public for my public content instead of Content and rather use Content for files that I want to bring in untouched like source files (see here one usage of Content).