I need to versioning my javascript files and think the best way is to generate the sha1/md5 of each file and rename it with that result (and the reference to each js file too obviously) during the build process.
This way, when a file content changes, its name changes too and I have not to worry about versioning anymore.
I am trying to find some info about how to make this works with maven but I don't find anything related to.
Any help?
Related
I'm writting some typescript code and I would like that no other developpers can directly edit compiled files created with Typescript. Is there a way to automaticly make readonly generated files ? Or maybe to encrypt compiled files to force next devs to use typescript original files. I know if I write some comments like "Do not edit this file, use typescript version", they will not necessary be read...
Setting permission to prevent other developers from accessing the typescript files could be a tedious work. I suggest that you add comment on that typescript file that you want to protect from being modified so that other developers would be notified of your intention on that file.
Generally you separate your source files from your build files. Say for example you use Git you would only keep your source files in Git, not your build files. This way whenever another developer wants to work on your project they can only get the source files. They won't be able to change your build files because they do not have access to these.
Encrypting or making the files read only is not the way to go in this scenario. Educate your developers to not edit build files. And only share source files with your developers.
THIS link suggests that /app directory contains all configuration, templates (.html.twig files) and translations, and the /src directory contains PHP code.
However, HERE we can see that .css and .js files are loaded from /src/AppBundle/Resources/public directory and not /app/Resources/public directory. What is the best practice? How should I professionaly approach this problem, and where should I keep all the templates, .js and .css files?
I like to put css and javascript that serve for general purposes in /app/Resources/public and the ones specific to the concerned bundle in /src/YourBundleNameBundle/Resources/public. Like that when I want to see a code specific for a bundle I will just go to that bundle , when it's a general purpose code I would be sure that it's in the root. I have seen expert people doing it and it makes sense for me.
It's a matter of choice and there is no right and wrong answer.
the best practice is to put your css and js files in your bundle particularly in folder that you called "public" (yourBundle/Ressources/public/css/yourStyle.css)
and make sure to run this command before
php bin/console assets:install
and To avoid typing this command each time, I recommend you make a link (a kind of shortcut), by adding the active parameter:
assets:install --symlink
So, the web /bundles/folderBundle actually points to src/yourBundle/Resources/public
On Windows, you must run the command prompt in administrator mode
I am playing with the yoman trying to build a web site using the webapp generator.
If Managed to create a web site that works under grunt server, when I change a js file grunt notices the change change and does a live load and everything works as you would expect.
When I try a plan grunt, it attempts to run the dist task, it manages to include my html files, but skips any of the javascript or script files I created in the script and styles diretores. I assume its the case I have to tell grunt to includes these files
Files such as main.js seem to make it through, but there are no references to main.js in the Gruntfile, so I not sure which part of Gruntfile.js to change.
Doing a yo doctor reports
[Yeoman Doctor] Everything looks all right!
Q. How to do I tell grunt to include and user created files.
Q. I noticed that all my image files where renamed, fair enough how do I refer to a file that I known is going to be renamed in a javascript file
Q. Does anybody known a good web resource for yoman where these quesion might have already been answered?
Be careful on this glob pattern scripts/{,*}/*.js. This takes only the js files that are inside scripts or immediate child folders.
Make sure to change it to scripts/**/*.js to include all js files in all subfolders.
Also get an idea on tags build: css, build: js in your index.html, wiredep plugin used by Yeoman in gruntfile to understand what files will be injected into dist folder.
I'm trying to implement some cache busting on my angular application in a way that it will still allow caching but break it anytime we push new code to production. My setup so far involves using grunt cache-breaker https://www.npmjs.org/package/grunt-cache-breaker to dig through my concatenated angular app.js file and append query params to any string ending in a .html file extension. I also do this for any template files I have that are using an ng-include. One complication this creates is that now I need to first copy my template files to a dist/ directory so I can safely .gitignore the cache-busted versions and not have to commit all of my templates everytime the cache is busted (and create conflicts).
My question is not how to do this but more of a sanity check as to if this is a practical way of avoiding template caching on new code? I have seen examples of disabling template caching in angular but it seems like it is something I would want to use in between code pushes when files are not changing.
How do other navigate this issue?
I think a popular approach is to use something like ng-templates (with a grunt plugin) to generate a JS file that pre-caches all of your templates. Then use the usemin grunt workflow along with an asset versioning task to version the JS file.
I use Visual Studio 2013 and .NET 4.5 for an MVC project.
I've learning to use AngularJS via several videos on Pluralsight and one of them walks through the process of using Grunt to clean the output directory, then use ngmin to min-safe the Javascript files.
My process is using a gruntfile.js to clean and run ngmin against the javascript files in my solution, then put them in a directory called app_built. This is executed via a batch file in the pre-build for the project and then I include it via a ScriptBundle with IncludeDirectory pointing to the app_built directory. My intent is to use the Bundling features of .NET 4.5 to do the rest of the minification and concatenation of the Javascript after all the files have been min-safed via Grunt.
I specify the path to the min-safed files with the following:
bundles.Add(new ScriptBundle("~/bundles/minSafed")
.IncludeDirectory("~/app_built/", "*.js", true));
If I run this on my local machine, it runs fine without a hitch. The Javascript is minified and bundled as I'd expect and the resulting web application runs fine as well.
If I publish the website to a remote server, I get a server error that the "Directory does not exist. Parameter name: directoryVirtualPath". I assume this error is saying that it's unable to find the directory populated with my many *.js files. I also assume this is because they weren't published since they aren't part of the solution, even though the folder they reside in is a part of the solution (it's just empty within the solution explorer in Visual Studio).
If my assumption is correct, what can I do to add these files to my solution so they'll be published with the rest of my web application with minimal effort on my end each time?
And if I'm incorrect in the assumption, what I can I do to resolve this otherwise?
Thanks!
I never did find a great way of going about this. I found information at http://sedodream.com/2010/05/01/WebDeploymentToolMSDeployBuildPackageIncludingExtraFilesOrExcludingSpecificFiles.aspx that seems related, but I was unable to make it work.
Rather, since I knew the name of the outputted file, I simply created such an empty file in my project and referenced that where I needed to. I then had the pre-build task replace the contents of that file with the externally minified version and it would be packaged with the project as necessary, so it works well enough.