I'm working on a AngularJS application and using gulp for the build-process. I have multiple JavaScript files (for controllers, services, directives, etc.) which I concat, uglify and then inline into an index.html in order to minimize the amount of server connections.
Here comes the problem:
When I do not inline the concatenated and uglified JavaScript files into index.html, the sourcemaps work when I debug the application with the developer tools.
When I do inline the JavaScript files into index.html, then my breakpoints are never hit. Why? I'm not sure, what I'm doing wrong.
This is the relevant part of my gulpfile:
// isPublish is set to true to uglify.
// the temp-folders are here just for testing purposes, I tried with
// and without and I have also changed the order of the gulp-command.
return gulp.src(definition.srcs)
.pipe(sourcemaps.init())
.pipe(replace("$build:serverApiBaseUrl$", args.serverApiBaseUrl || "..."))
.pipe(gulp.dest(targetFolder + "/temp1"))
.pipe(concat(definition.targetFile))
.pipe(gulp.dest(targetFolder + "/temp2"))
.pipe(gulpif(isPublish, uglify()))
.pipe(sourcemaps.write("./"))
.pipe(gulp.dest(targetFolder));
Please see here for the whole solution, e.g. for the project structure, etc. Even though I think this isn't really of any relevance for my problem.
Another thing I realized is that even though the breakpoints get hit (when not using the "inlined"-mode), the variable names are still in the mangled format (i.e. only letters). Is this a expected browser behavior (i.e. do developer tools not support this?), or do I need to specify something special for the sourcemaps-command? I don't understand why, as the generated sourcemaps contain the names-information.
Update I (13.10.2015)
I realized I could also use following method:
return gulp.src(paths.target + "index.html")
.pipe(inline({
base: paths.target,
js: uglify()
}))
.pipe(gulp.dest(paths.target));
This however doesn't seem to work due to a issue in gulp-inline. There seems to be a pull request, no idea when it will be merged back though. And even if it would work, I'm not sure what will happen with the sourcemaps in that case..?
Update II (19.10.2015)
Version 0.1.0 of gulp-inline has been released today (see pull request mentioned in "Update 1" which has now been merged back). It now works correctly with gulp-uglify, i.e. the bug has been fixed. I still couldn't get the sourcemaps to work though. Not sure if this is supported by gulp-inline.
So for the time being, I'm still searching for a solution..
Related
I'm trying to change the url in my app from "http://www.test.com/foo" to "http://www.test.com/bar+someVariable" (somevariable is a string that I recieve from an http request inside bar's controller) using history.pushState() . In my routes I enabled html5mode and everything works fine. I'm also using location.path() to switch between views and controllers as instructed in the docs. Now once the app switches view and controller I added history.pushState(null,null,"/bar"+somevariable) to "/bar"'s controller. Everything works and the url is updated but in the console I receive the "10 $digest() iterations reached. Aborting!" error. I suspect that activating the history.pushState function is somehow interfering with angular's $location or $route service.
What is the correct way to use history.pushState() within angular without receiving the $digest error?
By the way I'm using angular 1.0.3
Thanks ahead,
Gidon
Change the path with
$location.path('/newValue')
See: http://docs.angularjs.org/guide/dev_guide.services.$location
It is hard to know for sure without seeing the relevant source, but this is a common issue in older versions of IE (8 and 9 mostly I think). The solution that worked for me a few weeks ago when I encountered this (and may work for you if you're using IE) was changing my anchor tags in my navigation.
I had:
what fixed it:
I don't know if this a really noob question, but I have seen a lot of documentation about use Express in node.js and Express. But What I see is that they always use another lenguage called "Jade" for rendering an HTML file. Why? I'd like to know if its necesary use Jade or I can render templates in Express with HTML.
No, it's not necessary to use Jade with Express. It's just a popular option since Jade is the default for generated applications and is maintained by the same developer as Express.
They also tend to stay up-to-date with each other, such as the addition of template inheritance in jade as express dropped support for layouts.
But, there are a number of other view engines that offer built-in support for Express. And, the consolidate project can be the mediator/glue so you have even more options:
atpl
dust
eco
ect
ejs
haml
haml-coffee
handlebars
hogan
jade
jazz
jqtpl
JUST
liquor
mustache
QEJS
swig
templayed
toffee
underscore
walrus
whiskers
Note: I believe I misunderstood your question and answered too broadly at first. But, leaving the rest of what I wrote below in case it's still useful.
It's not necessary to use a view engine with Express, but can be helpful.
Express can simply .send() a value as the response:
res.send(new Buffer('whoop'));
res.send({ some: 'json' });
res.send('some html');
But, a view engine like Jade can help with generating more complex, data-driven content from a view/template. They can also help to keep your project organized by intent (separation of concerns), since views are typically kept in their own files.
Albeit, a view engine is necessary if you want to use res.render(). This method depends on the 'view engine' application setting or that you've configured an app.engine().
app.set('view engine', 'jade'); // or ejs, swig, etc.
# ...
res.render('a-view'); // looks for `a-view.jade` based on `'view engine'`
app.engine('jade', require('consolidate').jade);
# ...
res.render('a-view.jade'); // matches the extension to the `.engine()`
If you do decide to use Jade, there are multiple ways of inserting your data, including placing raw HTML in an element in your jade file. You can also insert fragments of HTML if you manually bypass the sanitizers with !{ locals.someHtmlString }
You can check out a demo of the below Jade code (albeit without passing in the locals variables) here: http://cssdeck.com/labs/qkkrzfes
//app.js
app.get('/', function(req, res){
locals.someData = {foo:'Bar'};
locals.someHTML = '<span>hello</span>'
res.render('someTemplate');
//someTemplate.jade
!!!
html
head
body
p.someClass This is plain text that goes in the paragraph
p#someId You can insert data into the text: #{locals.someData.foo}
p <a href='/'>You can just slap HTML in willy nilly</a>
p HTML is escaped by default: #{locals.someHTML}
p Escape HTML with \!{}: !{locals.someHTML}
pre
code=JSON.stringify(locals.someData, null, 2)
When I view files on GitHub, tabs appear as 8 spaces.
Example:
Is that possible to change this configuration to 2 or 4 spaces?
You can append ?ts=2 or ?ts=4 to the URL to change the tab-size.
Example: https://github.com/jquery/jquery/blob/main/src/core.js?ts=2
It seems that the value can be anything from 1 to 12. It does not work on Gists or raw file views though.
Source: GitHub Cheat Sheet
Set default displayed tab size for your repository
When you have a .editorconfig in your repository it will respect it
when viewing code on GitHub.
indent_style = tab and indent_size = 4 shows tabs with 4 columns
instead of 8
https://github.com/isaacs/github/issues/170#issuecomment-150489692
Example .editorconfig for multiple extensions which works in JetBrains' products:
root = true
[*]
end_of_line = lf
insert_final_newline = true
# Matches multiple files with brace expansion notation
[*.{js,jsx,html,sass}]
charset = utf-8
indent_style = tab
indent_size = 4
trim_trailing_whitespace = true
[*.md]
trim_trailing_whitespace = false
Change how you see tabs on other repositories
Install Stylus in your browser, than install GitHub: better-sized tabs in code.
There are also Google Chrome extensions:
https://chrome.google.com/webstore/detail/github-tab-sizer/djpnapkcpjomnkfekaedkigfomiedpjf
https://chrome.google.com/webstore/detail/github-tab-size/ofjbgncegkdemndciafljngjbdpfmbkn/related
Since Sept. 2021, you can set the tab size directly in your GitHub settings: github.com/settings/appearance.
Announced in Changelog "Tab size rendering preference".
No more .editorconfig
No more ?ts=2 added to the URL
Just:
Note: you cannot enter "3" for instance. You would get:
Tab size rendering preference could not be saved:
Validation failed:
Tab size is not included in the list
It actually is possible to do it, with a browser extension. Install Stylish (in Firefox or Chrome), then install this user style: “GitHub: better-sized tabs in code”.
It might not work for some languages. For example, I was viewing a JavaScript file and I did not notice any changes. So I deleted the style the author had and put the following lines into it:
.tab-size {
-webkit-tab-size: 4 !important;
-moz-tab-size: 4 !important;
-o-tab-size: 4 !important;
tab-size: 4 !important;
}
And it worked on Chrome (screenshot).
As you can see from the screenshot, I also enabled widescreen mode and changed the color scheme to Solarized. So I have three user styles running on GitHub pages via the Stylish extension for Chrome. I hope this helps someone.
Update
Yes. As stated by mortenpi, this can be done by through an additional query parameter. See his answer for more details.
Original answer
Is that possible to change this configuration to 2 or 4 spaces?
No. It's only available as part of the editing feature through the Ace editor and the change is not persisted.
This blog post gives some more information about the embedded IDE.
However, provided you know the url of the blob (file) you're willing to review, you can switch to the edit mode easily by changing the blob segment with an edit segment and use the dropdown to select your prefered tab size.
Standard view: https://github.com/moroshko/mmSelect/blob/master/mm_select.js
Ace view: https://github.com/moroshko/mmSelect/edit/master/mm_select.js
If the project is yours, create a file in the project root named “.editorconfig” and give it the following contents.
[*]
indent_style = tab
indent_size = 4
This will cause GitHub to render tabs 4-wide within the project.
This is an EditorConfig file, which is formally specified, supported by many editors, and also supports more extensive editor configuration, like specifying that all .html files are UTF-8 encoded.
If the project isn’t yours, consider opening an issue requesting the author specify the indent style they intended.
If you're into UserScripts, this did it for me:
// ==UserScript==
// #name GitHub Tabs
// #namespace http://foldoc.org/
// #version 1
// #description Set sensible tabs on GitHub
// #author Denis Howe
// #match https://github.com/*
// ==/UserScript==
document.querySelectorAll('table').forEach(t => { t.dataset.tabSize = 2 });
I did that for fixing them http://valjok.blogspot.com/2014/07/indentation-correction-for-exposing.html.
Another option is when embedding your gist, replace all tabs with required number of spaces
<div id="willReplaceTabs">
<script src="https://gist.github.com/valtih1978/99d8b320e59fcde634ad/cf1b512b79ca4182f619ed939755826c7f403c6f.js"></script>
<script language="javascript">
var spaces = " "
willReplaceTabs.innerHTML = willReplaceTabs.innerHTML.replace(/\t/g, spaces)
</script>
</div>
If it's an option for the project you're working on, changing your editor to treat tabs as spaces will fix the problem.
So, for example, in Visual Studio Code, the config looks like this:
{
"editor.tabSize": 2,
"editor.insertSpaces": true
}
In Sublime it's:
{
"tab_size": 2,
"translate_tabs_to_spaces": true
}
Until recently I insisted on non-spaced tabs. After switching, it fixed the Github rendering weirdness, and I haven't noticed any significant downsides in my workflow.
The best solution is, if possible, to convince maintainers of the source code you're looking at to replace all the tabs by the correct number of spaces.
Using tabs is problematic in code today given that you're often seeing it on the web, where the decision of "how many spaces per tab" depends on where it's being displayed.
I have been looking at a HTML 5 boilerplate template (from http://html5boilerplate.com/) and noticed the use of "?v=1" in URLs when referring to CSS and JavaScript files.
What does appending "?v=1" to CSS and JavaScript URLs in link and script tags do?
Not all JavaScript URLs have the "?v=1" (example from the sample below: js/modernizr-1.5.min.js). Is there a reason why this is the case?
Sample from their index.html:
<!-- CSS : implied media="all" -->
<link rel="stylesheet" href="css/style.css?v=1">
<!-- For the less-enabled mobile browsers like Opera Mini -->
<link rel="stylesheet" media="handheld" href="css/handheld.css?v=1">
<!-- All JavaScript at the bottom, except for Modernizr which enables HTML5 elements & feature detects -->
<script src="js/modernizr-1.5.min.js"></script>
<!------ Some lines removed ------>
<script src="js/plugins.js?v=1"></script>
<script src="js/script.js?v=1"></script>
<!--[if lt IE 7 ]>
<script src="js/dd_belatedpng.js?v=1"></script>
<![endif]-->
<!-- yui profiler and profileviewer - remove for production -->
<script src="js/profiling/yahoo-profiling.min.js?v=1"></script>
<script src="js/profiling/config.js?v=1"></script>
<!-- end profiling code -->
These are usually to make sure that the browser gets a new version when the site gets updated with a new version, e.g. as part of our build process we'd have something like this:
/Resources/Combined.css?v=x.x.x.buildnumber
Since this changes with every new code push, the client's forced to grab a new version, just because of the querystring. Look at this page (at the time of this answer) for example:
<link ... href="http://sstatic.net/stackoverflow/all.css?v=c298c7f8233d">
I think instead of a revision number the SO team went with a file hash, which is an even better approach, even with a new release, the browsers only forced to grab a new version when the file actually changes.
Both of these approaches allow you to set the cache header to something ridiculously long, say 20 years...yet when it changes, you don't have to worry about that cache header, the browser sees a different querystring and treats it as a different, new file.
This makes sure you are getting the latest version from of the css or js file from the server.
And later you can append "?v=2" if you have a newer version and "?v=3", "?v=4" and so on.
Note that you can use any querystring, 'v' is not a must for example:
"?blah=1" will work as well.
And
"?xyz=1002" will work.
And this is a common technique because browsers are now caching js and css files better and longer.
The hash solution is nice but not really human readable when you want to know what version of file is sitting in your local web folder. The solution is to date/time stamp your version so you can easily compare it against your server file.
For example, if your .js or .css file is dated 2011-02-08 15:55:30 (last modification) then the version should equal to .js?v=20110208155530
Should be easy to read properties of any file in any language. In ASP.Net it's really easy...
".js?v=" + File.GetLastWriteTime(HttpContext.Current.Request.PhysicalApplicationPath + filename).ToString("yyMMddHHHmmss");
Of coz get it nicely refactored into properties/functions first and off you go. No more excuses.
Good luck, Art.
In order to answer you questions;
"?v=1" this is written only beacuse to download a fresh copy of the css and js files instead of using from the cache of the browser.
If you mention this query string parameter at the end of your stylesheet or the js file then it forces the browser to download a new file, Due to which the recent changes in the .css and .js files are made effetive in your browser.
If you dont use this versioning then you may need to clear the cache of refresh the page in order to view the recent changes in those files.
Here is an article that explains this thing How and Why to make versioning of CSS and JS files
Javascript files are often cached by the browser for a lot longer than you might expect.
This can often result in unexpected behaviour when you release a new version of your JS file.
Therefore, it is common practice to add a QueryString parameter to the URL for the javascript file. That way, the browser caches the Javascript file with v=1. When you release a new version of your javascript file you change the url's to v=2 and the browser will be forced to download a new copy.
During development / testing of new releases, the cache can be a problem because the browser, the server and even sometimes the 3G telco (if you do mobile deployment) will cache the static content (e.g. JS, CSS, HTML, img). You can overcome this by appending version number, random number or timestamp to the URL e.g: JSP: <script src="js/excel.js?time=<%=new java.util.Date()%>"></script>
In case you're running pure HTML (instead of server pages JSP, ASP, PHP) the server won't help you. In browser, links are loaded before the JS runs, therefore you have to remove the links and load them with JS.
// front end cache bust
var cacheBust = ['js/StrUtil.js', 'js/protos.common.js', 'js/conf.js', 'bootstrap_ECP/js/init.js'];
for (i=0; i < cacheBust.length; i++){
var el = document.createElement('script');
el.src = cacheBust[i]+"?v=" + Math.random();
document.getElementsByTagName('head')[0].appendChild(el);
}
As you can read before, the ?v=1 ensures that your browser gets the version 1 of the file. When you have a new version, you just have to append a different version number and the browser will forget about the old version and loads the new one.
There is a gulp plugin which takes care of version your files during the build phase, so you don't have to do it manually. It's handy and you can easily integrate it in you build process. Here's the link: gulp-annotate
As mentioned by others, this is used for front end cache busting. To implement this, I have personally find grunt-cache-bust npm package useful.
Does anyone know of an extension for Firefox, or a script or some other mechanism, that can monitor one or more local files. Firefox would auto-refresh or otherwise update its canvas when it detected a change (of timestamp) in the files(s).
For editing CSS, it would be ideal if just the CSS could be reloaded, rather than a full HTML re-render.
Effectively it would enable similar behaviour to Firebug with its dynamic HTML/CSS editing, only through external files.
Live.js
From the website:
How?
Just include Live.js and it will monitor the current page including local CSS and Javascript by sending consecutive HEAD requests to the server. Changes to CSS will be applied dynamically and HTML or Javascript changes will reload the page. Try it!
Where?
Live.js works in Firefox, Chrome, Safari, Opera and IE6+ until proven otherwise. Live.js is independent of the development framework or language you use, whether it be Ruby, Handcraft, Python, Django, NET, Java, Php, Drupal, Joomla or what-have-you.
It has the huge benefit of working with IETester, dynamically refreshing each open IE tab.
Try it out by adding the following to your <head>
<script type="text/javascript" src="http://livejs.com/live.js"></script>
Have a look at FileWatcher extension:
https://addons.mozilla.org/en-US/firefox/addon/filewatcher/
it's a WebExtension, so it works with the latest Firefox
it has a native app (to be installed locally) that monitors watched files for changes using native OS calls (no polling!) and notifies the WebExtension to let it reload the web page
reload is driven by rules: a rule contains the page URL (with regular expression support) and its included/excluded local source files
open source: https://github.com/coolsoft-ita/filewatcher
DISCLAIMER: I'm the author of the extension ;)
I would recommend livejs
But it has following Advantages and Disadvantages
Advantages:
1. Easy setup
2. Works seamlessly on different browsers (Live.js works in Firefox, Chrome, Safari, Opera and IE6+)
3. Don't add irritating interval for refreshing browser specially when you want to debug along with designing
4. Only refreshing when you save change ctrl + S
5. Directly saves CSS etc from firebug I have not used that feature but read on their site http://livejs.com/ that they support it too!!!
Disadvantages:
1. It will not work on file protocol file:///C:/Users/Admin/Desktop/livejs/live.html
2. You need to have server to run it like http://localhost
3. You have to remove it while deploying on staging/production
4. Doesn't serves CDN I have tried cheating & applying direct link http://livejs.com/live.js but it will not work you have to download and keep on local to work.
Xrefresh with firebug.
Firefox has an extension called mozRepl.
Emacs can plug into this, with moz-reload-on-save-mode.
when it's set up, saving the file forces a refresh of the browser window.
There are some IDE's that contain this ability (They'll have a pane within them or some other means to auto-refresh a page on save).
If you want to do this yourself a quick hack is to set the meta refresh on the page to a low value - one or two seconds.
# Will refresh the page content every second
<meta http-equiv="refresh" content="1" />
You could just place a javascript interval on your page, have it query a local script which checks the last date modified of the css file, and refreshes it if it changed.
jQuery Example:
var modTime = 0;
setInterval(function(){
$.post("isModified.php", {"file":"main.css", "time":modTime}, function(rst) {
if (rst.time != modTime) {
modTime = rst.time;
// reload style tag
$("head link[rel='stylesheet']:eq(0)").remove();
$("head").prepend($(document.createElement("link")).attr({
"rel":"stylesheet",
"href":"http://sstatic.net/mso/all.css?v=4372"
})
);
}
});
}, 5000);
Browsersync can do this from the server side / outside of the browser.
This can achieve more repeatable results / things that don't require so much clicking.
This will serve a page and refresh on change
cd static_content
browser-sync start --server --files .
It also allows a scripting mode.
This is certainly hacky, but if you want to work locally without making any external request (to live.js, for example), or run any local server, I think this might be useful. This is not specific to web development, you can adopt similar strategy to any other workflow.
You will need two tiny tools (which are present in almost all distribution repos): inotify-tools and xdotool.
First get the ID of your Firefox and your editor window using xdotool.
$ xdotool search --name "Mozilla Firefox"
60817411
60817836
$ xdotool search --name "Pluma" # Pluma is my editor
94371842
Depending on the number of processes running, you will get one or more window ID. Use xdotool windowactivate <ID> to know which one you want (the focus changes to the respective window).
Use inotifywait -e close_write to monitor changes to your local file and when you save the file using your editor, change focus to your browser, reload xdotool key CTRL+R and focus back to your editor. This is so instantaneous you will not notice nothing.
Also, inotifywait exits on change, so you might have to do it in a loop. Here is a minimum working example (in Bash in your working directory).
while /usr/bin/true
do
inotifywait -e close_write index.html;
xdotool windowactivate 60917411; # Switch to Firefox
xdotool key CTRL+R; # Reload Firefox
xdotool windowactivate 94371842 # Switch back to Pluma
done
You can use inotifywait to watch for the entire directory or some selected files in your directory.
You can write a script that can automate is easily.
This works on Linux (I've tested this on Void Linux.)
You can use live.js with a tampermonkey script to avoid having to include https://livejs.com/live.js in your HTML file.
// ==UserScript==
// #name Auto reload
// #author weirane
// #version 0.1
// #match http://127.0.0.1/*
// #grant none
// ==/UserScript==
(function() {
'use strict';
if (Number(window.location.port) === 8000) {
const script = document.createElement('script');
script.src = 'https://livejs.com/live.js';
document.body.appendChild(script);
}
})();
With this tampermonkey script, the live.js script will be automatically inserted to pages whose address matches http://127.0.0.1:8000/*. You can change the port according to your need.
I think that you can solve it by using some ajax requests after a determinate interval. You can do a request to CSS files and then if you don't get the "not modified" header you delete your css and load it again. For dynamic files you do a request and store the response and then every time you make a request to that file you compare the response to the latest.