Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Should I store .coffee files in git and compile them server-side with some git hooks, or should I store both .coffee and .js files in SCM and just ignore coffee at the server?
Are there any disadvantages to storing compiled .js files except extra SCM space usage? I'd rather not have to install node, npm and coffee on each server.
The workflows that I've seen are for Rails and Node. My current process is based on them and looks like:
Keep .coffee files in /assets/src/coffee
Keep compiled .js files in /assets/js and reference them as /js/foo.js
Keep .js files that are external to your app (e.g. a graphing utility) in /assets/lib
Exclude /assets/js from your source control
Set up your middleware to compile coffeescript files on the fly if they aren't already compiled. connect-coffee-script was the one I liked best.
The process in Rails is pretty similar, to the best of my recollection.
Are there any disadvantages to storing compiled .js files except extra SCM space usage? I'd rather not have to install node, npm and coffee on each server.
I see no good reason to put compiled js into source -- your middleware should handle turning coffee into js. I also see no disadvantage to installing coffee on your server -- you should be doing an npm update as part of your build process and that should take care of it.
Here's the code for setting it up:
var app = express();
...
srcFolder = path.join(__dirname, 'assets', 'src', 'coffee');
publicFolder = path.join(__dirname, 'assets');
app.configure(function () {
...
app.use(require('connect-coffee-script')({
src:srcFolder, dest:path.join(publicFolder, 'js'), force:true
}));
It's also important to note that I had some issues getting this going on Windows 7; node's file watchers seem to have some issues there. So I have to have a command window with this running while developing: coffee -o ./assets/js -wc ./assets/src/coffee.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I created my own API using the IBM Watson Personality Insights API. Then, I created a website that would retrieve the the JSON object from the API and display it in a sunburst diagram, just like in the Personality Insights Demo.
I have found a library that displays the information how I want from a JSON object: https://github.com/personality-insights/sunburst-chart . The problem is that the instructions say that I must insert this two lines of code into my HTML file:
<script src="https://cdnjs.cloudflare.com/ajax/libs/d3/3.5.14/d3.min.js"></script>
<script src="path/to/personality-sunburst-chart.standalone.js"></script>
I know the second line must be changed accordingly to where personality-sunburst-chart.standalone.js is, but that file doesn't exist in the library. I thought that maybe they had changed the library and forgot to update the instructions, so I tried pointing it to index.js file inside the /lib folder of the library. Once I did that the browser console started alerting me that the file couldn't be executed because it contained require() commands, that can't be executed in web JavaScript.
Where can I get the missing file?
I found the answer.
Explanation
In all 1.x.x versions of the library, the whole library came precompiled in the /bin directory in the form of a JavaScript file named "personality-sunburst-chart.standalone.js".
The current version is 2.x.x, the installation method changed, but the instructions weren't changed.
Current installation instructions for the 2.x.x version
The current version doesn't come with a precompiled file. To get it, you have to follow the following instructions:
You have to download the repository and run npm install to install all the necessary dependencies. After that, you must run npm run compile. Once that finishes, the standalone file will be in the /dist directory with the name index.js.
The command script is: node_modules/.bin/browserify --full-paths -t [ babelify --presets [ es2015 ] ] --standalone PersonalitySunburstChart lib/index.js -o dist/index.js
You can then change the name to "personality-sunburst-chart.standalone.js" if you want and copy it to your web page directory.
Then, you can reference the final script with :
<script src="personality-sunburst-chart.standalone.js"></script>
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm a little lost as to how I should proceed, actually I don't even know where to start.
I've been working on a few wordpress sites lately, usually I create a dev environment using npm grunt.
I set up a folder and do npm init. Then I install all the grunt plugins I need such as: watch, sass, uglify etc... I then download wordpress and set up the gruntfile.js so that for example my sass will compile to my wordpress theme's stylesheet. Just the usual (I hope).
The thing is rather than always repeating the same step over and over I'd like to automate it ( same config step for each site ).
So here is my question, how do you go about creating a script that will automaticaly install grunt plugins and configure them, download the latest wordpress and set up the theme files ( domain name etc...)?
I don't need an explanation on how to do all these steps but just a few pointers on where to start and what tools to use would be great. Being quite the novice in script writing any information is good to use.
Try yeoman.
There is yeoman generator for wordperss boilerplate. It uses gulp instead grunt, but has same idea that you need.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I need to implement configuration files for an application im developing.
I was wondering whether it is better to use INI files or JS files(JSON data)
for the configuration files.
What are the security concerns? Could a file permission be set to the js files that a user cannot retrieve them via the browser but the php can read them?
Best way to handle that kind of configuration is to keep it outside of your public directory, so that users won't be able to access it.
Generally in web applications you have web-accessible directory. For example: web/ in Symfony 2.x and public/ in Laravel 4/5. In these folders you would usually find index.php file which user runs when accesses your website. If you move your file outside of this folder - (cd ..) - into your application root directory where you might see directories like vendor/ then here you could store files which ordinary user would not be able to download just using some link to the file.
About file extension. Actually lately it has become quite popular to name your config files in "dot" format. For example: production or .my_config which not only protects you from users accidentally downloading files (since dot files are usually not accessible), but it also lets you keep your config files out of version control software such as git, so your passwords won't end up on github.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
In the past I've used a yeoman-generator Grunt for all of my dev tasks. Usually when working on a project I'll use it with compass to compile my scss, and then package and uglify my JS, optimize images, lint my code, and many other useful things.
Recently I've seen a trend towards people to use webpack instead of grunt plugins for many of these tasks. Why is this? What is better about a module bundler in this regard?
I'm sure others have their reasons, but the biggest reason why I migrated to webpack (more specifically webpack-dev-server), is because it serves your bundle from memory (as opposed to disk), and its watcher will recompile only the files you changed while reusing the rest from cache (in memory). This allows development to be much faster. What I mean is, while I am actively editing code, I can ctrl + s in Sublime Text, by the time I alt + tab to Chrome, it's already done rebuilding. I had a grunt + browserify + grunt-watch setup before, and it took at least 5 seconds to rebuild every time I save (that is after I've made bunch of specialized optimizations in grunt build). That being said, I still integrated webpack with gulp, so I got a task-runner for my project.
EDIT 1: I also want to add that the old grunt + LESS/SASS + browserify + uglify + grunt-watch setup didn't scale well. I was working on a major project from scratch. At first it was fine, but then as the project grew, it got worse every day. Eventually it became incredibly frustrating to wait for grunt to finish building every ctrl + s. It also became apparently that I was waiting for bunch of unchanged files.
Another nice little thing is that webpack allows you to require stylesheets in .js, which establishes coupling of source files in the same module. Originally we established stylesheet dependencies by using import in .less files, but that disconnected source files in the same module and established a separate dependency graph. Again all of these are highly opinionated, and this is just my personal opinion. I'm sure others think differently.
EDIT 2: Alright after some discussions below, let me try to offer a more concise and less opinionated answer. One thing that webpack does really well is that can watch, read, preprocess and update cache and serve with minimal amount of file I/O and processing. Gulp pipe works pretty great, but when it comes to bundling step, it inevitably ends up having to read all of the files from a temp directory including those unchanged. As your project grow, wait time for this step grows as well. On the other hand, webpack-dev-server keeps everything cached in memory, so the amount of wait time during development is kept minimal. However to achieve this kind of memory caching, webpack will need to cover from watch to server, so it will need to know your preprocessing configs. Once you have configured webpack to do just that, you might as well just reuse the same configs for spiting out builds other than dev server. So we ended up in this situation. That being said, exactly what steps you want webpack to do is still up to your personal preferences. For example, I don't do image processing or lint in my dev server. In fact, my lint step is a totally separate target.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
so i completed building a new angular application and i would like to deploy it into production... of course i have prepared all my angular code such that it can be minified so i am covered there!! But something i dont understand... i have very good code separation and full unit testing of my application... as a result, of course, there are a lot of script tags on my main page.
I need to of course debug my javascript during runtime as i develop, but then when i go to deploy i need to minify. What is the best practice here? Is this literally a manually process of replacing the script tags with my all.min.js file after i move the code to the production machine? Do i minify all the css and html as well?? I am using gulp for the minification...
thanks for the help....
In the absence of server side templating (like Razor or Thymeleaf) I would suggest using gulp-preprocess, gulp-processhtml, or gulp-html-replace.
Use gulp to concat your files in development as well as production. You'll probably want to use gulp-sourcemaps to be able to debug your client-side javascript as if they were separate files.
Here's a sample gulpfile.js
gulp.task('script', function(){
gulp.src('./app/**/*.js')
.pipe(sourcemaps.init())
.pipe(concat('application.js'))
.pipe(sourcemaps.write())
.pipe(gulp.dest('./build'))
})
gulp.task('script:prod', function(){
gulp.src('./app/**/*.js')
.pipe(concat('application.js'))
.pipe(ugilfy())
.pipe(gulp.dest('./build'))
})
Then in your view, just point it at the build file.
<script src="/build/application.js"></script>
When you deploy, run gulp script:prod. In development, run gulp script.