I'm learning to use webpack-encore and noticed it is installed only as a dev dependency. Does that mean I should compile my js and css files on development and push them to the repository, and then to production?
That seems to me what the docs are implying, but wouldn't that mean a merge-conflict hell? Compiled files would be impossible to merge.
Also wouldn't that be contrary to version control philosophy? As far as I know, you don't publish binaries in compiled languages (i.e. C/C++), you push the code and expect the server to compile them. I know this isn't the same type of "compilation" in javascript, but what is the expected behavior of the production server in this case? To receive the files ready to serve them, or to compile them at the time of release?
Thanks in advance
Does that mean I should compile my js and css files on development and push them to the repository, and then to production?
Not exactly - it depends on how you deploy.
When you deploy, you need to run ./node_modules/.bin/encore production to build your assets. Once you've done this, only your built assets (e.g. web/build) need to be transferred to production.
You could run this command locally (or on some "build" server) and the transfer all the files to production. Or, you could use a git pull on production, and then run this command on production (the downside being that you would need Node.js installed on production).
You shouldn't / don't need to commit your built files to your repository. But... if it simplifies your deploy (i.e. you want to do a git pull and be done), there's no real problem with that.
I just added a PR to answer these in the FAQ (http://symfony.com/doc/current/frontend/encore/faq.html) - here's the PR until it's deployed: https://github.com/symfony/symfony-docs/pull/8109
Cheers!
Solution 1:
Run yarn run encore production locally
Check out which files have been created / modified
Add them to VCS
Commit
Push / deploy
Solution 2:
Push / deploy
Run yarn run encore production remotely during deployment
To my eyes the 2nd solution is way better, because you don't need an extra human-checking before deployment, everything is automated.
But this has a strong drawback: building assets can be a slow process, and when I deploy, my production is down during 5 to 20 seconds until assets are built.
Here's the HTTP 500 error:
An exception has been thrown during the rendering of a template ("Asset manifest file "[...]/web/build/manifest.json" does not exist.").
It looks like the manifest.json file is deleted at the beginning of the process, and created from scratch later on.
Something that should be improved?
Related
I am doing my first angular project and I have to upload it to a Development test server. Problem is that, an Angular project (event in default state) has so many files that it takes a lot of time to upload it.
I investigated and the .gitignore file seems only to be to avoid the commit of the files or folders specified there.
Could you please tell me if there is a way to minimize the number of needed files to upload and install or use them later, in local, in a safe way? Without risks of corrupting the project.
If you are using Angular CLI you can get a production build by doing
npm run -- ng build --prod
in the project directory. This will create a minified, bundled version of your app in the dist folder, ready for upload. You will then need an http-server running to serve these files.
As #yarz-tech suggested, the solution was to remove the node_modules each time I upload it. Then, when someone downloads it and wants to work with it again, must execute npm install. That allows npm to install all the dependencies our project needs, based on what is is specified on the package.json file, which appears not only for Angular projects, but for Node for example.
Thanks to everyone.
I am currently trying to generate native versions of a small meteor app I built. When I run them on iOS or Android via the meteor run command it works and meteor build with --debug also generates an ipa/apk that works as expected. But when I run meteor build without --debug the web view only shows a white screen. Using remote debugging I noticed an injector error. I was wondering why and checked the apk/ipa content. There I recognized that in the debug version under assets/www/application/packages there is a bunch of .js and .js.map files which simply is not there in the non-debug ipa/apk.
In the index.html of the non-debug ipa/apk the imports of these files are also missing.
How can I tell meteor to just copy these obviously required files for non-debug?
When you build, Meteor concatenates and minifies all the JS files into a single bundle, same as Browserify and webpack are doing. That is why you do not see all the script imports.
It does not do it in debug to facilitate live reload / hot code push while you are developing, besides facilitating debugging​ obviously.
See the Meteor guide on building for production.
If you believe this difference causes some issue, you can simulate it in development using the --production flag after meteor run.
This addresses your titled and last question, but may not fix in itself your initial issue.
I'm working on node.js app that is written in Typescript, which means it needs to be compiled to JS before running. As I'm coming from java/jvm background where you ship prebuilt package to server and it gets run there I'm a bit afraid of the way of deployment where you push code to git and it's being built/compiled on server first and then run.
I don't like it for two main reasons:
dev dependencies need to be installed on server
deployment depends on external resources availability (npm etc).
I found NAR https://github.com/h2non/nar which is more or less what I wanted but it has some drawbacks (doesn't work with some deps that have native extensions).
My question is: is there any other "sane" way of doing deployment node.js deployment than this risky combination of npm install and tsc on server? Or should I let that sink in and do it that way?
To be honest I don't believe there are no more sane/reliable options for that.
What you can do (but there are probably other perfectly valid approaches) is building your project locally (or on a CI service), and only deploy this built version when you consider it as valid (tests, etc.).
This way, if something bad happens, like npm that fails, or a compilation error, you don't deploy anything, and you have time to resolve the situation.
For example, I used to have a gulp task (but it can be anything else: Grunt, a simple npm script...) that clone a production repository and build the project into this directory.
That way, I can check that my build is valid. If it is, I make a new commit and push it to the production repo, that is served the way you need (on a Heroku instance for example).
Pros
Clear separation of dev and non-dev dependencies
Deployment only when you know that the build is valid
No built files on source control on the development repository
No "live" dependency on external tasks like npm install or tsc build
Cons
You have two separated git repositories (one with the source code, one with the built version of your project)
Production process is a little bit heavier than simply committing to master
(From comment) Doesn't properly handle the case of npm package that relies on native extensions that have to be (re)built
is there any other "sane" way of doing deployment node.js deployment than this risky combination of npm install and tsc on server
package.json + npm install + tsc is the way to do it. Nothing risky about it.
More
Just use an npm script : https://github.com/TypeStrong/ntypescript#npm-scripts
What's the best practice for minifying and bundling js/css in a pure front end app, and how do the tools work?
I know how this can be done with server side apps like .NET/Java/LAMP/etc. But what about pure front end projects, SPA projects or backendless projects that are built with say, ember or angular these days? Say your entire project consists of HTML/css/js, which interfaces with a RESTful service elsewhere.
What kind of process or tool do you use to minify and bundle the resources for that?
I've seen grunt plugins that exist for this, but I find the documentation to be pretty magical and it's still unclear to me how they work.
Specifically, does the tool:
1) Replace src="/js/a.js",src="/js/b.js" with src="/js/bundle-a+b.min.js"? (and likewise with css?) in the source html files?
2) have different modes for dev and release, or is the tool only run when the project is released?
Or are the resource requests entirely managed by a js tool and js/css files have to be requested via a library function? Wouldn't the lag be noticeable in this case?
Thanks.
Through the use of Build tools front end devs can have minified javascript, css, or even images and html files automatically minified as they develop. The most common is grunt, with gulp close behind.
You configure grunt tasks, like grunt-contrib-uglify and grunt-contrib-copy, and put those tasks under a grunt-contrib-watch task. Have the grunt watch task watch the files you modify, and every time a change is detected those .min files are automatically generated.
These build tools have no impact on your application, they are run before the files are servered. You were correct to assume there was an easy way to do this. I suggest you look at grunt getting started, a sample gruntfile, or a project that uses grunt - here's mine, it does minification like you requested. Clone my repo, run sudo npm install, then sudo grunt. I don't have watch set up in my project but grunt is very well documented.
I'm deploying the project to the server after deploying CSS and images - it's working, but the JS doesn't work - 404. JavaScript hash in HTML and public/assets - mismatch.
In HTML: application-6851a5d9167871936c32da723dca0f23.js
In public/assets: application-95ecf5bab4b7984abe8c1c23b72a7679.js
Did you run 'rake assets:clean assets:precompile'?
Also, if you're using GIT, you'll need to 'git rm' the older versions of the assets too. You'll need to do something similar for other version control systems if you Production environment is updated by pushing a workspace (e.g. Heroku).
In your Development environment, Assets are fetched directly from your source base - so if you change them, you don't need to precompile again (saving you time during development). But, you can stumble on the assets fairly easily because of that.
Restarting the app fixed it for me.
E.g. in the app's root directory:
touch tmp/restart.txt
or in Capistrano 3's deploy.rb:
namespace :deploy do
desc 'Restart application'
task :restart do
on roles(:app) do
within release_path do
execute :touch, 'tmp/restart.txt'
end
end
end
after 'deploy:publishing', 'deploy:restart'
end