I'm new to developing with Meteor and node-based apps.
I intend to create a PR for a problem i noticed in Rocket.Chat.
I git cloned the Rocket.Chat dev branch and made a change to a certain file:
https://github.com/RocketChat/Rocket.Chat/blob/develop/packages/rocketchat-oembed/client/oembedImageWidget.html
After that i ran the build-script successfully. My build started, but the change is not included.
Using the Chrome Dev Tools to inspect the change, i still see the original unchanged code.
I know it's a rather generic question and i'm sure the solution is kind of stupid, but any idea why ?
Thank you.
Kind regards
It looks like the file you modified is in the packages directory. This is dealt with differently.
Check the .meteor/packages files to see if this package is referenced, if it is, then it will install the package from the atmosphere package management system.
Here the steps required to make your changes work...
1) Edit the .meteor/packages file and change the reference to rocketchat:oembed to be simply oembed
2) Edit the file packages/rocketchat-oembed/package.js and do the same thing, change rocketchat:oembed to be simply oembed
Package.describe({
name: 'oembed',
version: '0.0.1',
summary: 'Message pre-processor that insert oEmbed widget in template',
git: ''
});
I think you can leave the directory names as is.
Meteor will now use your local package instead of going out to get the published version of it
In addition to #Mikkel's answer: I think you don't have to change package name, but just change its version. That should be enough for Meteor to rebuild this package from its source and you won't have any dependency issues.
Related
I am developing a small meteor package, and I know that, to be consistent with the builds, meteor will create a .versions file in my package when I publish it.
That's fine, and I understand that, but, as the .versions should go in my version control (git) and I would like to commit the release before publishing it, is there a way to update the .versions package before publishing?
Also, the .versions file has a reference to the package itself. Is this necessary? If I'm developing version x.y.z of a package, why do I need to update both the package.js and the .versions file to reflect x.y.z?
Thanks,
Oliver
I don't think there's a need to add it to version control b/c I don't think the set of calculated versions means anything in a stand-alone package outside of the context of a meteor project. I'm not really sure what the file is used for at all since it doesn't show up in .meteor/packages when you install the package. It might just be nothing more than a by-product of running the solver.
So I never check .versions into version control and I haven't encountered any problems.
Following the guidelines here: http://docs.ionic.io/docs/push-from-scratch I am having trouble with step 2 - installing ionic add ionic-platform-web-client.
My index file within my app adds <script src="lib/ionic-platform-web-client/dist/ionic.io.bundle.min.js"></script> as it should, however the file doesn't exist at this location, even after running 'ionic lib update'.
(For ease of explanation in this section I am using the non minified version of the bundle: ionic.io.bundle.js (the results are the same with both full and minified versions of the files)).
Manually adding ionic.io.bundle.js from https://github.com/driftyco/ionic-platform-web-client/tree/master/dist will give me this error:
"Uncaught TypeError: Cannot call method 'get' of undefined
ionic.io.bundle.js (3429,0)"
from this code:
key: "get",
value: function get(name) {
return this._settings.get(name);
}
I found a 'hacky' way to get the dev pushes working by simply returning this instead of the full return this._settings.get(name) statement, although this only really suits the purpose of debugging and additionally does not allow removal of developer mode by settings 'ionic config set dev_push false' or manually setting "dev_push":false in .io-config.json.
I am unsure as to whether manually adding ionic.io.bundle.js is simply adding to my problems or whether this is the right approach to take and that the errors produced are the real problem?
I am running:
ionic 1.1.0
ionic CLI 1.7.7,
cordova 5.3.3,
bower 1.6.2,
npm 2.11.3,
visual studio 2015 community with cordova/ionic setup,
I've also updated my android platform - for which I am currently building to (deploying to nexus 7).
TheCannot call method 'get' of undefined in ionic.io.bundle.js happens because of missing settings in the bundle.
This could be fixed by running:
ionic config build
Although I still haven't been able to install the ionic web platform via 'ionic add ionic-platform-web-client' in the cli I have managed to get the ionic push notifications working.
Firstly I made sure in my app directory within the cli to use 'ionic lib update'. As the setup of my project was different (thanks to visual studio). You will likely already have these files using a custom setup, but I found it's good to have the directories in place.
Secondly I manually downloaded the web client https://github.com/driftyco/ionic-platform-web-client4 not just the ionic.io.bundle.min.js which seemed to fix my "Uncaught TypeError: Cannot call method 'get' of undefined" problem mentioned previously, after I moved the entirety of this in my lib directory. (Make sure the name of the downloaded folder matches: "ionic-platform-web-client" exactly, and doesn't contain any words like master).
Thirdly, as I couldn't add version 1.3.0 of the push plugin (which continually gave me the beloved 'uh oh' error) I used 1.2.3 instead. I installed this via: 'cordova plugin add https://github.com/phonegap/phonegap-plugin-push.git#1.2.31'. Although I have just noticed 1.4.0 is available which may also work?
This should hopefully fix any issues you have, even if it's not a perfect solution. As a side note: I know it is mentioned somewhere on one of the ionic pages that you need to have a traditional project setup and then move the relevant files but it would be nice to have some description of how to go about this - as you may not know what the relevant files are. For anyone who comes here scratching their heads, If you're using visual studio to create your ionic projects from scratch or any other custom setup, you will likely run into the same issues, as the relevant directories created using 'ionic start myApp' will likely have been omitted.
There are two command line programs to start/stop/manage your meteor app. There is meteor and there is mrt. As of the latest build (0.8.2 or so) it's really not clear what the difference is between these two, if any. Both seem to support the argument "help" like meteor help and mrt help. The output of both seems to be the same to me.
Sadly, I do not see a "clean" argument available when I check the help for either of these. What do I need to do if I want to achieve a clean build? One that would
Blow away all packages and re-install them
Blow away any compiled templates
Blow away all Sass/Less compiled output
I ask this because I find myself in some kind of dependency Hades right now and want out now.
Meteor is still in a pre-release state. So the idea of packages is (still as of this post) not officially supported, though it will be soon. The meteor community stepped in to build their own way to use 3rd party packages and this is what meteorite does.
Most of the commands you give to meteorite are eventually passed to meteor which is why you see the same output.
The only (main difference is) mrt add which checks atmospherejs.com for packages first.
These two will be merged very soon (there is a branch on meteor on github called packaging which seeks to achieve this)
The idea of 'clean' isn't really there in meteor because most of the stuff is based on hot code reloads, so when a file changes its completely scrapped/(cleaned) and rewritten.
If you change a bit of code it will rebuild all this unless you have a syntax error.
Nonetheless if you want to 'clean' the build from everything you would have to do this in two steps (the meteor part and the meteorite part)
This erases some stuff in the hidden .meteor folder
meteor reset
Delete everything in ~/.meteorite/packages
Delete all symlinks only in your projects /packages folder. Be careful not to delete the folders because these will have been put in by you/whoever made your project and wouldn't be from atmosphere or meteor
Then run mrt update to reinstall all the atmosphere packages from scratch
In the MiniProfiler.MVC3 NuGet package, it creates a file in App_Start that is used to control MiniProfiler settings (the SqlFormatter to use, modifications to the ViewEngines, when to start MiniProfiler, etc.).
There are a lot of TODO comments in this file talking about how to change the code to perform how you want. This is great, but when the NuGet package is updated, it will see that I've changed the file and not pull down the updated version. The problem here is that I lose any updates to that file, and depending on what else updated in the package, making it unusable (for example, when upgrading MiniProfiler.MVC3 from version 1.9 to version 2.0.1 after modifying MiniProfiler.cs in App_Start, the project will no longer build because of needed changes to that file in the 2.0.1 version).
What is the best way to handle this? Should I create my own file in App_Start and not modify the one in the NuGet package, ensuring that I will always get the full update when upgrading to the latest version of the NuGet package?
You could backup the file in App_Start, update it, then merge the files manually, or using a merge tool. You'd probably end up doing this anyways if you're using source control.
Quick-and-dirty: create the file you want. Then copy over/merge every time you upgrade with nugget. Or with every compile. The added build time is negligible.
Slightly better: use the precompile event in visual studio and compare the files. If they differ - either copy over or tell the user. I can't figure out a way to show a message box, or similar, on the top of my head but one could always create a new file with a compilation error and some text nearby "discrepancy in the xxx file".
try using mercurial queues. You can get your code to the point you want (excluding the file you refer to), and then commit. Make changes to your file, and push it to a queue. Make sure to exclude it from any future updates (manually), and then when you want to update your package, pop it off your code base. This will make it look like it used to, and run the nuget update. Then you can push the queue back to the code, and your changes will re-applied. It might take a bit of fiddling, but worth a look.
For reference:
https://www.mercurial-scm.org/wiki/MqExtension
https://www.mercurial-scm.org/wiki/MqTutorial
https://developer.mozilla.org/en/Mercurial_Queues
I've got a multi-project ASP.NET Web Forms Application solution. I need to share a master page (3 files), some user controls and some images, scripts and CSS files out to the other projects in the solution.
I have already created a package using the NuGet Package Explorer per the documentation:
http://docs.nuget.org/docs/creating-packages/using-a-gui-to-build-packages
My current problem is this: I have updated the shared files in the root project and now I want to update the package before pulling it into the other projects (package currently in a local folder on my dev machine). How do I do this?
If anyone has some getting-started-quickly NuGet links, please share as the official docs just aren't doing it for me.
create the package again with a new version aka if the orginal is 1.0 make this 1.1 and NuGet will pick up the update.
The NuGet file is ultimately just a zip file. You can update entries using anything that can update a zip file. Such as something like
using System.IO.Compression;
using System.IO.Compression.FileSystem;
// EG: AddOrUpdateZipEntry("mypackage.nupkg", "my.dll", "bin/my.dll")
void AddOrUpdateZipEntry(string zipFilePath, string contentsFilePath, string entryPathInZip)
{
using (var zip = ZipFile.Open(zipFilePath, ZipArchiveMode.Update))
{
zip.GetEntry(entryPathInZip)?.Delete(); // Remove any existing entry first.
zip.CreateEntryFromFile(contentsFilePath, entryPathInZip);
}
}
Are you asking what you need to do to update projects that are already using the package?
The key thing in this kind of scenario is simply versioning. The new version of the file will be sub'd out. Bundle up the package again with a new version number and then run Update-Package from the package manager console in VS.
You may also want to consider a couple of discreet packages, rather than one straight one. If you want to update a couple images or a CSS file, but not the MasterPage, it might work best to have a couple smaller ones.
Use the PM Explorer (from the post you mentioned) to open a couple packages from the NuGet main repository, in particular, jQuery 1.5.1 and 1.6.x and have a look, as these will be doing very similar things. No real magic needed!
Cheers.
I've already done it before. You just have to increment the version of your package, inside metadata of .nuspec file.
In my case, my packages names are '[name].[version].nupkg' so I save my new package as '[name].[version +1].nupkg' as well.
The update apears in 'Manage nuget packages' updates section.