As asked previously in Have Grunt include different Javascript files in development and production and Have Grunt generate index.html for different setups
I want expanded assets includes for development:
<script src="js/lib-1.js"></script>
<script src="js/lib-2.js"></script>
<script src="js/lib-3.js"></script>
...
And for production or staging:
<script src="js/all-files-in-one.js"></script>
However, I don't want to synchronize my include code in two places. For most of the available answers, I have to specify the list of files in grunt task first and then replicate the include code again in the html. The closest solution I could find is this answer: https://stackoverflow.com/a/21488659/515585, in which I only need to maintain an array of files in the grunt task. And all the answers requires a daunting amount of setup to make it work.
An even better solution would allow me to use sprocket syntax to require other asset files right in the context of the code (instead of using a build file) a la Rails asset pipeline. And expand them with a single switch of variable, so I could debug each individual file in development. I've looked at the grunt-sprockets-directives, but I don't see it offer the expanding option. Maybe it does?
I would like to not use asset pipeline from my backend framework, and I am asking for any front end build tools, not just grunt specifically. Gulp, Yeoman, or even better Broccoli.js answers are also appreciated.
Related
I'm developing a progressive web app using Vue.js.
While I'm developing I use the command npm run dev to start the local server which serves the files on http://localhost:8080/. When I want to build for production I use npm run build prod which generates the output files in project\dist. I then take those files and copy them onto an ISS which is configured to work with single-page applications. All good so far.
I noticed some differences in the way the app looks (css) between the dev and prod build. First I thought this might be because of a client side cache, but after several tries to clean the cache and no-cache loading I'm sure that caching is not the issue here. The output really is different.
To be honest, I'm not sure if there is anything else different besides a few minor css parts. I was thinking what might be the issue, one of the things I noticed that could be the cause is that I use single file components in vue with scoped css (*.scoped.vue.css file names). I guess there could be an issue combining the different files into a single one?
It might be noted that I'm quite a newby when it comes to npm, webpack and all the other involved technologies. If you want to take a look at the configuration, you can find my current working branch build configurations here.
Any idea what the issue might be?
I encountered the same problem when using single file components. The issue indeed seems to be that when you run npm run build it will generate one single css file without the guarantee that the styling will be applied in the same order, causing some property values to be ignored. I 'fixed' it by adding !important to the properties that weren't matching up in the final build. There's probably a better way to handle this, but I must admit I too am quite a newby.
The order of how styles are applied while npm run build matters, and is to my knowledge out of (y)our control. To get rid of conflicts, when using Vue.js, you may want to scope your styles.
In every *.vue file within your project, replace
<style>
...
</style>
With
<style scoped>
...
</style>
I'm a bit new to Symfony and I'm don't know what to use for my static file management. I have read about Assets component and the Assetics bundle.
I know that Assets just includes the files and Assetics is a bit smarter as it can combine files and compress images. But I already use compass to minify and combine the css files so therefore Assetics is not really required.
Version control so the url of the static files change to by pass browser cache, is done by both.
Assetics is removed from 2.8 or higher, does this mean it is not best practice anymore?
I need to generate urls on three places:
Twig -> Easy to do with both
Controller -> Found only a way to do this with Assets
In css files -> Believe it is with both not possible
Wat would be the best to use in my case, any advise?
Assetic can be seen as a way to easily apply filters and compile your assets. The asset component basically is used to manage URL generation. As you said, both nicely are integrated in Twig via extensions, and controllers via the services.
Our application uses compass too, but Assetic makes sure that the compiling happens at the right moment without the need of compass watch at the commandline.
Think most of your questions are answered on:
http://symfony.com/doc/current/cookbook/assetic/asset_management.html
and
http://symfony.com/doc/current/components/asset/introduction.html
I've been using the RjFrontendBundle to run the front-end CSS/JS build, and also copy other static content into place from Bower/NPM/local sources. It provides a VersionStrategyInterface for the Assets component that creates, and uses unique filenames in production (renaming the files with an embedded hash, via the GulpJS rev-all package). In dev, it uses the normal filename.
Within CSS files, you can still reference CSS/JS, via a url() function, and the pipeline will rename them appropriately in dev and live.
The GulpJS build tool is used to minify and otherwise prepare the plain files. It comes with a setup console command to build the initial gulpfile.js and can also watch and rebuild files, updating the browser as they are changed, which helps with front-end development workflow.
The trend is to use standalone front end tools such as gulp/grunt/sass instead of assetic. The reasons are (probably) as follows:
gulp / grunt are independent from the framework, providing the same workflow for the front end guy no matter what underlying framework is used for the backend.
assetic has a different workflow than most of the modern tools. It assumes that you will write your script/css includes in the templates. Migrating from assetic to gulp could be a pain for large project.
as your project grows, assetic can become kind of slowish... As that happens, you will stop pulling your assets from the controller and start generating them the way gulp or grunt does. In this scenario, gulp and grunt are just better tools.
assetic lacks some important features, such as including processed assets into HTML code (inline). Because of the way assetic works (twig tags), it might be difficult to overcome this.
As for generating the URLs: assets are just files in the filesystem. Write a function or twig extension to generate URLs to those files.
I'm using the accordion, tooltips and transition components of UI Bootstrap.
I can create a custom build with the online tool on the UI Bootstrap website, which will create a minified and non-minified JS file containing only the components I selected, without overhead.
However, I don't want to use the online tool to compile my custom version of UI Bootstrap, instead I want to compile my own version locally, preferably using the tools I already use; Bower, Grunt and NPM.
So my question: How can I create my own version of UI Bootstrap locally?
bower install angular-ui-bootstrap, and then calling Grunt build in bower_components/angular-ui-bootstrap creates a UI Bootstrap build that includes all modules, there's probably a way to do the same with only a subset of the modules, but I could not figure this out.
It can be done by using the following command
grunt build:moduleName1:moduleName2:moduleName3....:moduleNameN
For example if you require the build to contain only tabs and buttons module , then the grunt command will be like
grunt build:tabs:buttons
The generated files will be present in dist folder
For the list of module names , check all folder names in src folder
The documentation for this is sparse , but if you check the Gruntfile.js , where they register the build task , they mention about how to build modules selectively
It is not as easy as I expected (and as it should be).
Take a look at the Gruntfile.js of the project. You will see that they do quite a lot. Converting HTML and CSS to JS, concating all the scripts in such way they are loadable by others. Moreover the file is quite difficult for orientation; it even includes custom tasks.
To mimic its behaviour I suggest this: Download it via Bower as you normally do. Copy its node dependecies to your package.json dependencies. Then copy the Gruntfile.js, change he routes, and try deleting some parts of the code until you reach a point when you cannot remove more lines without breaking it. It is not a nice way, it should be however successful.
If one had a lot of time, the build script is a good candidate for a deep refactoring. Moving custom tasks to standalone files (or projects), documenting the flow, and maybe implementing standard tasks for some steps (e.g. CSS minification).
This is a noob question.
I would like to use grunt.js as a build tool for my web project. Can use grunt.js to validate my HTML/CSS files? Do you have an example of such a grunt.js file?
There is another plugin that seems to be updated more often and does not require java. grunt-html-validation. It has a number of options and has been working great for me. You can install and use it like this:
npm install grunt-html-validation --save-dev
Then put something like this in the initconfig of your Gruntfile.js
and this in appropriate places in your Gruntfile.js
grunt.loadNpmTasks('grunt-html-validation');
grunt.registerTask("default", ["validation"]);
There is also a number of useful options including the ability to relax errors based on a regular expression (could be useful for AngularJS for example) and the ability to save a report.
You can use the grunt plugin grunt-html. Beware, you will need Java on your computer to use it. It works well for me.
As of now there seem to be two popular HTML validation plugins:
grunt-html-validation
grunt-html
grunt-html-validation uses the W3C Markup Validation Service and grunt-html uses a local copy of the java-based The Nu HTML Checker.
They both work well and have very similar options so it comes down to whether you want to wait for an external service call or wait for a local java app.
I am currently using PHP minify to combine and compress the static files (CSS and JS). With PHP minify it is very easy to develop and deploy. Because:
Say there are two files: a.js and b.js and we combine and minify them in ab.js. Now its enough for me to include only one script tag:
<script type="text/javascript" src="http://static.example.com/min/g=ab&v=7"></script>
With this flexibility I can develop in a.js and b.js and at the same time test the final minified version without changing the include tag above. I don't even need to change while releasing.
But now I want to move my static files to CDN server where PHP won't be there, so I guess I have to use YUI compressor to minify and combine before uploading. Now If I am combining a.js and b.js with YUI compressor, I have to change the include tag which I used to develop.
So when developing I've to use:
<script type="text/javascript" src="http://static.example.com/a.js"></script>
<script type="text/javascript" src="http://static.example.com/b.js"></script>
And when uploading I've to use:
<script type="text/javascript" src="http://static.example.com/ab.min.js"></script>
Then it becomes a problem because, the two lines has to be combined into one. Whats your setup to manage this?
Specify the base URL to ab.min.js (i.e. http://static.example.com/) in a config file. In the production config, use the CDN location. In your development config, use the automatically minified location.
Looks like you're comfortable with using different base URLs for development and production, but that combining two lines into one is your problem.
If this is the case, perhaps you want to split this step in two.
Combine a.js and b.js manually into ab.js, but don't minify. You only need to do this once. Now during development you can work directly on the source code in ab.js.
Before uploading, typically as an automated step in your build process, use YUI compressor to minify ab.js.
If you want to keep a.js and b.js separated, then the above will not work for you and you probably need some kind of preprocessor that will modify the script tags in your source code as required.