As in the title - how would one go about removing comments from both JS and CSS files when being compiled though Broccoli.
I am using Broccoli as part of Ember-CLI.
When you build your project you have to set the environment to production, it defaults to development.
ember build --environment production will concat, minify and uglify your scripts and css removing all comments.
For more info refer to this part of the docs.
Related
I'm writing automation test for the angularjs web app. Using protractor and cucumber.
From beginning, I organized the test as a separate folder and actually it required different node packages from the root project(the project built up the web app).
Today there's a requirement that the node_modules of test project should be merged with the node_modules of root project.
As per my knowledge, when running the command protractor protractor_conf.js, the system looks for the node_modules in 1 level upstream folder.
I'm attaching the screenshot of my project folder to be clearer.
Appreciate all suggestions !
Thanks.
I will not recommend you not to save node_modules as the separate folder in the project directory. Instead, you can create a package.json file for your test project and list all the dependencies in the package.json file. so each time before you run protractor conf.js ,just run npm install command from the directory where your project is available. So by doing this way will help you to run the e2e scripts in different machines without depending on the node_modules folder.
Example package.json for protractor
Also, it is advisable to maintain separate node_modules for different project because it may avoid versions conflicts of any node_module that is used in both projects.
I want to start learning ReactJs with jsx and Babel. My editor is Visual Studio Code. I need to config them to work together in VSCode, but after search in Google and StackOverFlow, I found dispersed contents for different frameworks and platforms. Is there any resource to learn step by step configuration and using react in VSCode?
Thanks a lot
I found babel-standalone in GitHub .
babel-standalone is a standalone build of Babel for use in non-Node.js environments, including browsers. It's bundled with all the standard Babel plugins and presets, and a build of babili (babel-minify) is optionally available too.
With babel-standalone we can compile out JavaScript files with jsx format in browser. Easy installation and usage.
I've created a new foundation project using the foundation new myproject --libsass method.
Its just a simple static index.html (for the purpose of this question).
I've deployed it to a live server now, and I am wondering about the best way to structure this. I have omitted the node_modules & scss directories, and i'm left with the following:
bower_components/
css/
js/
index.html
bowerrc
bower.json
Gruntfile.js
humans.txt
package.json
README.md
bower_components is needed in its current form, unless I shuffle some files around, which is what I intend to do, but I'm checking if there is a better way of doing this, and that I haven't missed some magic terminal command to deploy to production.
As msturdy suggested in the comments, grunt is the way to go here. There are a lot of plugins out there, see a list on the official page.
If you want to have grunt "compile" your project into one specific folder which you can then for example push to a deployment server, you should do several things in grunt:
compile your scss
minify your javascript, that is making the files smaller, see jscompress for a demo of what it is. All your js-files from /bower_components which you include in your project should be in a vendor.js which is loaded first, and then a second js-file should contain your custom js from /js
save everything into a deployment folder.
(optional) automatically deploy to a server.
Take a look at these grunt tutorials for setting up your gruntfile.js, you'll want to have two tasks, one for just quickly compiling your scss, one for the whole deployment process:
grunt is not weird and hard
official tutorial
sitepoint tutorial
They show you how to do certain things and definitely how to write the gruntfile. Plugins you might want to use apart from your current libsass plugin are uglify and any plugin that lets you deploy your code via git, ftp or anything else. You can download all these plugins via npm by adding them to your package.json and doing npm install, refer to their websites for exact usage instruction.
Since I first saw a dist/ directory in many open source projects, usually on GitHub, I've been wondering what it means.
With dist, vendor, lib, src, and many other folder names that we see quite often, I sometimes wonder how I should name my own folders.
Correct me if I'm wrong!
src: Contains the sources. Sometimes only the pure sources, sometimes with the minified version, depends on the project.
vendor: Contains other dependencies, like other open source projects.
lib: Good question, it's really close to vendor actually, depending on the project we can see one or another or both...
dist: From what I saw, it contains the "production" files, the one we should use if we want to use the library.
Why is open source so confusing? Isn't it possible to do things clearer? At least per language because some languages use specific names.
To answer your question:
/dist means "distributable", the compiled code/library.
Folder structure varies by build system and programming language. Here are some standard conventions:
src/: "source" files to build and develop the project. This is where the original source files are located, before being compiled into fewer files to dist/, public/ or build/.
dist/: "distribution", the compiled code/library, also named public/ or build/. The files meant for production or public use are usually located here.
There may be a slight difference between these three:
build/: is a compiled version of your src/ but not a production-ready.
dist/: is a production-ready compiled version of your code.
public/: usually used as the files runs on the browser. which it may be the server-side JS and also include some HTML and CSS.
assets/: static content like images, video, audio, fonts etc.
lib/: external dependencies (when included directly).
test/: the project's tests scripts, mocks, etc.
node_modules/: includes libraries and dependencies for JS packages, used by Npm.
vendor/: includes libraries and dependencies for PHP packages, used by Composer.
bin/: files that get added to your PATH when installed.
Markdown/Text Files:
README.md: A help file which addresses setup, tutorials, and documents the project. README.txt is also used.
LICENSE.md: any rights given to you regarding the project. LICENSE or LICENSE.txt are variations of the license file name, having the same contents.
CONTRIBUTING.md: how to help out with the project. Sometimes this is addressed in the README.md file.
Specific (these could go on forever):
package.json: defines libraries and dependencies for JS packages, used by Npm.
package-lock.json: specific version lock for dependencies installed from package.json, used by Npm.
composer.json: defines libraries and dependencies for PHP packages, used by Composer.
composer.lock: specific version lock for dependencies installed from composer.json, used by Composer.
gulpfile.js: used to define functions and tasks to be run with Gulp.
.travis.yml: config file for the Travis CI environment.
.gitignore: Specification of the files meant to be ignored by Git.
To answer your original question about the meaning of the dist folder:
The shortform dist stands for distributable and refers to a directory where files will be stored that can be directly used by others without the need to compile or minify the source code that is being reused.
Example: If I want to use the source code of a Java library that someone wrote, then you need to compile the sources first to make use of it. But if a library author puts the already compiled version into the repository, then you can just go ahead. Such an already compiled version is saved into the dist directory.
Something similar applies to JavaScript modules. Usually JavaScript code is minified and obfuscated for use in production. Therefore, if you want to distribute a JavaScript library, it's advisable to put the plain (not minified) source code into an src (source) directory and the minified and obfuscated version into the dist (distributable) directoy, so others can grab the minified version right away without having to minify it themselves.
Note: Some developers use names like target, build or dest (destination) instead of dist. But the purpose of these folders is identical.
Summary of the folders:
bin: binaries
contrib: contributions to the project
dist: -- see 1. and 2.
doc/s: documentation
include: headers (C/C++)
lib: libraries (C/C++)
man: short for man/manual pages (Unix/Linux), c.f. man(1)
src: source
"/dist means "distributable", the compiled code/library." ref.
"The shortform dist stands for distributable and refers to a directory where files will be stored that can be directly used by others without the need to compile or minify the source code that is being reused." ref.
Actually! "dist folder" is the result you get after modifying a source code with "npm run build" or "ng build" or "ng build --prod" for production.
Meanwhile! After getting "dist folder" there might still be few things that you still need to do depending on your project type ✌️
I'm trying to make a workflow where i can just run grunt deploy and it minifies images, css, javascript, concatenates all the css and javascript, with usemin, change the include scripts in the html to all the minified files, then finally pushes the changes. The only thing is, the next time i want to edit the files, i want to edit the regular javascript and css files, but the files being included in the html are the minified files. How would i get around this? I was thinking to make a production and development html file and ignore the development html for deployment, but is there a better way?
Give a different deployment folder for production environment and development. That is, when minify, specify the destination(dest) files into another folder which is production root. use 'copy' plugin to copy the html to that folder and 'usemin' to use that html as input.
You may need other plugins to help, 'clean' to clean the files under production before grunt deploy.
The only thing you need do is deploy to different website, grunt with those plugins will help you all the others.
Try Yeoman. It will set you up with a comprehensive build script that puts all the built files in a subdirectory, leaving your source files intact.