I'm looking at a git repo for a jquery plugin. I want to make a few changes for use in my own project, but when I opened up the repo it had a structure I've never seen before. I'm not sure which files to use / copy into my own project.
There is a "dist" and a "src" folder. What purpose do these serve? Is this something specific for gruntjs or maybe jquery plugins?
The git repo I'm curious about: https://github.com/ducksboard/gridster.js
src/ stands for source, and is the raw code before minification or concatenation or some other compilation - used to read/edit the code.
dist/ stands for distribution, and is the minified/concatenated version - actually used on production sites.
This is a common task that is done for assets on the web to make them smaller.
You can see an example here: http://blog.kevinchisholm.com/javascript/node-js/javascript-concatenation-and-minification-with-the-grunt-js-task-runer/
Related
I have a problem which can be easily solved by importing an external JS library into Node.js. However, this library does not exist in NPM.
I found out an old solution on StackOverflow which seems to fix the problem. However, it looks wierd.
Is there a more convenient solution in 2k20 to use external JS library methods into my Node.js code?
If your library have a package.json: You can install the package directly from the git repository, for example npm install https://github.com/vendor-creator/vendor-package. NOTE that for this method to work, in cases where the module has to be built, the git repository should contain a dist/ folder containing the built code or have in its package.json, a prepare step responsible for building the package upon installation.
If your library does not have a package.json and is simply a vanilla JavaScript file like the Lodash JavaScript file, I would advise just like in the post you linked, to create a vendor.js file (.min if the script is minified), copy and paste the content of the file and require it. Be aware that some libraries using CDN and not NPM, are designed for browser environment and may lack CommonJS support preventing you from using require. In that case you'll have to modify the library source code.
If it's a small library, there is no need to create an advanced build system. If the library is stable, just copy and paste it and you'll be fine. When in doubt always follow the K.I.S.S principle.
I am making an NPM package for the front-end and I want to know what the best file structure to use is. I have one code.js file and will have one code.min.js file. Should I have these two files in the root directory? In a dist folder? In a src folder? What is the best practice for this file structure - specifically on the front-end?
you should separate your source from your development compiled files, as much as possible.
For example on my projects, all minificated files, should be in a dist folder. The non minificated files, are not getting on the server. You wouldn't want a customer to accidentally use a non-min css and get 0.2 sec for extra load, would you? :)
Also, I do strongly recommend you to google this: "recommended structure [add framework name here]"
code.min.js is certainly the minified version of code.js. You simply need to add code.min.js to your project.
For node projects, you can insert directly the cdn link into your code or when you create a file ( js, css or image), it goes to the public folder.
I've created a bundle file of a private project of mine, and I would like to share it with someone. They ask me to provide the git bundle file generated.
Can I just email them the single bundle file? ...or do I need to attach the folder of the project itself as well?
Can I just email them the single bundle file?
Yep, that the point behind the bundle.
Its a full read-only repository.
Once you have the bundle you can share it.
git bundle will only package references that are shown by git show-ref: this includes heads, tags, and remote heads.
git bundle create ../reponame.bundle --all
--all- get all refs
This command creates bundle with all the source code and all other info like tags.
Even due that --all is not documented its much better to use it.
Note : --all would not include remote-tracking branches !!!
Question 1 :
I am installing my project dependency libraries using npm and it gets stored in the npm_modules folder. Is it necessary to keep the copy of library like angular.js,angular-route.js in lib folder or vendor folder? I could see few people are using lib folder or vendor folders to store the library in the permanent manner. I am confused by seeing this.
Question 2:
Do I need to copy/paste the node_modules folder to production or just run the npm install command on the project folder's command prompt to install all the dependencies in production. How does a dependency library get promoted to production?
Thank you kindly for your advice.
It all depends on how you need to deploy your site to production, really. Ultimately, you will probably want to bundle all your JS files into one or a few files, which are minified and sent with gzip compression.
How you bundle them is up to you. There are quite a few options:
Browserify
Webpack
Grunt / gulp build process
And many more besides
As to whether you need to keep a copy of these bundled javascript files under version control, well I think that boils down to 1 key question: can you run a build process (such as one of the tools using NodeJS) on the production server, or on a build server that creates a zip file or installer? If so, then you don't need to include them, just get the build server or production server to check out the latest copy from version control, npm install and then run the build process.
But if the best you could do is have the production server check files out from source control, then you would want to include the final versions of the files to use in the repository.
Keeping generated files, such as your bundled javascript files, in your source control repo should be avoided where possible. Because otherwise, every commit has to contain the changes to the source files, and the corresponding change to the generated files as well. And the latter is just noise, and has to be ignored by every developer looking at a diff/patch for a commit.
I was looking at Differential's meteor-boilerplate app and noticed that they do not use a bootstrap package and also saw a directory/file in the client directory that is related - client/compatibility/bootstrap.js
I was wondering if anyone had an explanation for why/when you'd want to avoid using a package like twbs:bootstrap and when you'd need to create a compatibility file.
I would say that it's the lazy path to include external libraries in a Meteor application.
You basically have two ways to achieve this include:
The road of glory. Create a package (meteor create --package), clone the source inside it, then edit and "Meteorize" the source (declare package-scoped variables instead of window-scoped, ...). You can then publish this package on Atmosphere so that others can benefit of it.
Copy/paste everything in a client/compatibility folder.
As explained in the docs, everything in this folder is not embraced with an IIFE and is executed before the other code files.
When you have the time to, be brave and take the heroes path.