In my Meteor project it looks like I've got two versions of jQuery running. My app is using the atmosphere package materialize:materialize and I know that one of its dependencies is jQuery. In my meteor/packages folder it shows version 1.11.10 being used.
But the confusing part is in my External Libraries folder. It also shows a version of jQuery 2.0.0. The only npm package that I have used for my app was when I brought in the babel runtime that was required for Meteor version 1.4.3.2. I had in the past installed Materialize from npm but removed it some time ago. Confused to why that jQuery 2 is there.
This is fine, it happens this way because of package dependencies, Meteor depends on what is quite an old version of JQuery, and one of your npm packages depends on 2.0.
It does seem strange, but it isn't a problem.
What is happening here is some of the meteor packages depends on jquery and some of the npm packages does the same so you end up having the lib installed twice. Nothing terrible except that clients would have to download the same library twice. This is a known bug here https://github.com/meteor/meteor/issues/6626. Not sure where is it going though, it's been there for quite long already.
Related
So have created an ASP.NET 4.5.2 project and now need to install react and typescript. I installed node.js so wondering if its best to install via that. Also because I will be using TypeScript I will need the .d.ts files is there an easy way to install these in the project locally? Cause I assume everything else will be installed globally by npm as I might use them in other projects?
One other thing I am confused by all the different types of react packages available on npm, do i need a few or just one of them? I have worked on many projects involving this kind of tech stack but they are established and have never created one from scratch like i am doing now. So some really informative links or tips here would be immensely helpful! :)
So using Visual Studio 2017 I followed this tutorial and managed to get it working. The only issue left now is that i need to call webpack cmd on the project root when i make changes before refreshing the site. I am fine with this and will look into further into automating it as it kind of is a different and unrelated question.
One thing I will include is to always install npm packages globally (most of the time anyway) and just link them in using npm link. Was quite useful considering I went through the process a few times creating the project from scratch over and over again until I understood it all.
I'm starting new app with meteor and I'm confuse when I have to install packages.
Meteor gives the possibility to install packages just like that:
meteor add <username>:<packagename>
Ok, very easy. The problem is that I would like use bower then, How I have to install the packages? For example angular.
meteor add urigo:angular
is the same as? what is the difference*? How I have to perform?
bower install angular
The logical conclusion could be use one of them, but I have seen in examples that they can be toguether.
*the package is recorded in different places, but the operation is the same?
With
meteor add <developer>:<packagename>
you add packages from the Meteor specific package database. Meteor packages are completely integrated into the Meteor eco-system and may contain both server and client side code.
You should use "meteor add" whenever possible.
To find Meteor packages you can use Atmosphere
Bower on the other hand is a framework independent package system for client side (mostly) JavaScript packages. It's not well integrated with Meteor - Although community packages exists to simplify usage of Bower packages with Meteor.
To answer you specific example:
meteor add urigo:angular
This command adds the Angular package of the Angular-Meteor project to your Meteor application. It's not only Angular but does also include some Angular services ($meteor) to provide integration of Meteor with Angular.
It even adds Angular support to the server side to some degree.
bower install angular
only downloads the official minified and non-minified javascript file of the latest Angular version for client side use.
You could use the Bower version with Angular but you wouldn't get the benefits of the integration.
While I don't use Bower myself, check out this package: https://atmospherejs.com/mquandalle/bower. I think it may help answer your question.
I am recently using gruntjs. It's amazing. I am using version 0.4.5
Every time when I am going to create a new project, do I need to install all dependency plugins that I needed? like grunt-contrib-uglify, grunt-contrib-sass etc.
Basically, I use 4-5 plugins for each project and just wonder to know that if there is away to use it globally.
Going through grunt doc, they said I have to install dependencies locally, that means all plugins for each project?
:(
Since Meteor 0.6.0+ supports npm packages directly, is Meteorite still relevant, and would there be any advantage/disadvantage to using it?
Meteorite is definitely still relevant and recent talks from meteor team indicate it will be folded into meteor itself eventually.
Meteorite does more than NPM, it also takes client side 3rd party libraries and specifies how they get integrated into a meteor app. In this aspect it serves the same purpose as yeoman/bower. 3rd party client side libraries like x-editable, sugar.js, moment.js, etc dont really belong in NPM, but you also shouldnt have to manually incorporate them into your meteor project either. See this comment from the meteor team: https://github.com/meteor/meteor/pull/516#issuecomment-12919473
Meteorite doesnt provide the full functionality of NPM. With just meteor, you cant just require a NPM package in your app and use it, even in 0.6.0+ you still have to make a package and an api wrapper. If you wanted to use a certain NPM and it was already wrapped and shared on meteorite, that would in effect provide a NPM 'proxy' via a meteorite package. Like this package https://atmosphere.meteor.com/package/ncp
I would suggest using meteorite for the capabilities you gain beyond meteor itself. However, be aware that this is an area in great flux so you may have to rework/adjust your project in the near term. IMO if you are building more than simplistic apps, you'll definitely want meteorite for the ease of incorporating 3rd party libraries.
Meteorite is still relevant at this point. Even though NPM packages are supported in meteor there isn't a community repo to add packages from (http://atmosphere.meteor.com)
Even though NPM modules can now be added they still need to be made to work with meteor.
Meteor code uses fibers to allow sync code to run so each NPM module being used still needs a package to let it be used in meteor which can make it easier to use (by allowing fibers code to be used in a project) with minor editing. Currently these packages have no other community place to go besides the atmosphere repo.
Now you can have full access to NPM.
Just do meteor add meteorhacks:npm
See my article: Complete NPM Integration to Meteor
Situation
I am working on an ASP.NET Web Forms project that was generated using the default Visual Studio 2012 project template. I have since then used NuGet to install jQuery UI version 1.10.0.
I need to update to jQuery UI 1.10.1 because there is a bug fix I need. According to the website, 1.10.1 is the current stable version. However, there is not a NuGet package available for this version!
I don't know why the NuGet package would lag behind the latest available stable release from the jQuery UI team on their website. (Yes, I realize there is probably a different team managing the nuget package itself... but it still seems like this needs to be kept up to date.... or the value of installing jQuery via NuGet is very limited.)
Question
How do I update jQuery UI (installed as a NuGet package) manually to 1.10.1 on my project?
I have already downloaded the latest 1.10.1 javascript files. Now.... when I look inside my ASP.NET Web Forms project, I see in the following files in the Scripts folder:
So what should I do here... delete the following two files?
jquery-ui-1.10.0.js
jquery-ui-1.10.0.min.js
...and replace with these new files?
jquery-ui-1.10.1.js
jquery-ui-1.10.1.min.js
This doesn't seem like it would work.
The way jQuery is being include in my masterpage (from the default template generated by Visual Studio 2012) is like this:
That JS bundle you see above, called "jquery.ui.combined" is auto-magically generated by some kind of hidden code. Go ahead and look through your project... you won't find anywhere obvious this bundle is defined. So if I add the latest JS files... it seems I have no way to define that they get used or bundled at all. They aren't the version that the NuGet package logic/code would be expecting!!!
Any ideas?
Another potential problem
When I downloaded jQuery UI 1.10.1, it also came with jQuery Core 1.9.1. As you will see above in my Scripts folder, it appears as if jQuery UI 1.10.0 goes hand-in-hand with jQuery Core 1.9.0. If I update jQuery UI..... do I also need to update to the matching jQuery Core as well? (These are separate NuGet packages)
Please answer this specifically
I would like for the answer to explain how to manually update the version of jQuery UI installed from NuGet package.... on an ASP.NET Web Forms project.
I think this would be useful so that in the future a developer can pull down the latest bug fixes as soon as they are included in a stable release on the jQuery UI website.... without needing to wait for the package to show up on the NuGet feed.
The jQuery UI team hasn't uploaded the version 1.10.1 for their package. I'm afraid you just have to wait until they release it.
If you can't wait, you can uninstall the current version of jQuery UI first, and then manually add the script files of version 1.10.1 into your project.
Work-around... although it seems like a bad approach....
I just opened up these files....
jquery-ui-1.10.0.js
jquery-ui-1.10.0.min.js
...and replaced the contents with the contents from these files:
jquery-ui-1.10.1.js
jquery-ui-1.10.1.min.js
I left the file names the same as they were. So even though the JavaScript files are named as version "1.10.0".... they are actually holding the code for version "1.10.1".
One of the reasons I think this might be a terrible idea
What happens if some other developer attempts to pull down my code from source control... and they use NuGet Package Manager to restore the packages they did not have yet. Wouldn't it pull jQuery UI nuget package and replace the JavaScript files I have modified with the ones from the nuget package? Then the page would start exhibiting the buggy behavior again, and no one would know why.
At the very least.... for now I can continue development with the bug fixed! It was very annoying... the overlay was appearing on top of the dialog and I couldn't interact with the page. Here is the bug that was fixed: http://bugs.jqueryui.com/ticket/8984
Go To : Visual Studio -> Tools => Library Package => And Package Manager Setting
Window opens Having Options as in Screenshot
Click On Add (+) Button At Right Top And Inside Source Browser To Your Folder Location of Whatever Package of Nuget You HAve. Name is Whatever You Want And Press Ok
You Can See Now Your Package Into Extensions And Updates Window
To Install In Current Project
use Package Manager console : Install-Package ANd your package name