FAQ and Common Issues
FAQ and Common Issues¶
How Do I Deploy My Encore Assets?¶
There are two important things to remember when deploying your assets.
1) Compile Assets for Production
Optimize your assets for production by running:
$ ./node_modules/.bin/encore production
That will minify your assets and make other performance optimizations. Yay!
But, what server should you run this command on? That depends on how you deploy.
For example, you could execute this locally (or on a build server), and use
rsync or something else to transfer the generated files to your production
server. Or, you could put your files on your production server first (e.g. via
git pull) and then run this command on production (ideally, before traffic
hits your code). In this case, you’ll need to install Node.js on your production
2) Only Deploy the Built Assets
The only files that need to be deployed to your production servers are the
final, built assets (e.g. the
public/build directory). You do not need to install
node_modules directory or even your source
asset files, unless you plan on running
encore production on your production
machine. Once your assets are built, these are the only thing that need to live
on the production server.
Do I Need to Install Node.js on My Production Server?¶
No, unless you plan to build your production assets on your production server, which is not recommended. See How Do I Deploy my Encore Assets?.
What Files Should I Commit to git? And which Should I Ignore?¶
You should commit all of your files to git, except for the
and the built files. Your
.gitignore file should include:
1 2 3
/node_modules/ # whatever path you're passing to Encore.setOutputPath() /public/build
You should commit all of your source asset files,
My App Lives under a Subdirectory¶
If your app does not live at the root of your web server (i.e. it lives under a subdirectory,
/myAppSubdir), you need to configure that when calling
1 2 3 4 5 6 7 8 9 10 11 12 13 14
// webpack.config.js Encore // ... .setOutputPath('public/build/') - .setPublicPath('/build') + // this is your *true* public path + .setPublicPath('/myAppSubdir/build') + // this is now needed so that your manifest.json keys are still `build/foo.js` + // (which is a file that's used by Symfony's asset function) + .setManifestKeyPrefix('build') ;
If you’re using the
Twig shortcuts (or are processing your assets through entrypoints.json
in some other way) you’re done! These shortcut methods read from an
entrypoints.json file that will
now contain the subdirectory.
“jQuery is not defined” or “$ is not defined”¶
This error happens when your code (or some library that you are using) expects
jQuery to be a global variable. But, when you use Webpack and
no global variables are set.
The fix depends on if the error is happening in your code or inside some third-party code that you’re using. See jQuery Plugins and Legacy Applications for the fix.
Uncaught ReferenceError: webpackJsonp is not defined¶
If you get this error, it’s probably because you’ve forgotten to add a
tag for the
runtime.js file that contains Webpack’s runtime. If you’re using
encore_entry_script_tags() Twig function, this should never happen: the
file script tag is rendered automatically.
This dependency was not found: some-module in ./path/to/file.js¶
Usually, after you install a package via yarn, you can require / import it to use
it. For example, after running
yarn add respond.js, you try to require that module:
But, instead of working, you see an error:
This dependency was not found:
- respond.js in ./assets/js/app.js
Typically, a package will “advertise” its “main” file by adding a
main key to
package.json. But sometimes, old libraries won’t have this. Instead, you’ll
need to specifically require the file you need. In this case, the file you should
use is located at
node_modules/respond.js/dest/respond.src.js. You can require
// require a non-minified file whenever possible require('respond.js/dest/respond.src.js');
This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.