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
Related
I just accidentally refactored QList to QSet, and Qt faithfully did it, to all of its own sources too... (yup, that was dumb!)
Thankfully my code is source controlled, I just reverted everything, would it be feasible/sensible to make a git repo for the Qt sources too? (I have the free version so I didn't think I could modify them anyway...?)
Is there a hidden setting that will prevent its sources from being modifiable, to stop me from doing this again?
I'm currently using the maintenance tool to install a newer version of Qt, but other than update or add/remove, there wasn't a re-install option that I could see, am I missing something?
There's no point to using source code control for an install: it's not source code. It's artifacts. You already know how to protect artifacts of all sorts from modification. Proper filesystem attributes will do it just fine.
Your finished Qt installation should not be writable by you. It would be by default on Unix systems when installed using a privileged package manager. Elsewhere: you need to make it read only. If you build from source, then recursively making the install folder read-only as the last step after installation is all it takes; and since you should be already automating your Qt build, then adding the "make read-only" step is trivial.
Thankfully my code is source controlled, I just reverted everything, would it be feasible/sensible to make a git repo for the Qt sources too? (I have the free version so I didn't think I could modify them anyway...?)
Feasible? Definitely. Sensible? Perhaps, assuming that by "make a git repo" you mean "cloning the official Qt repos from Git". It depends on how many times you plan on making the same renaming mistake. :D But seriously, I think there are benefits to building Qt yourself:
You can easily debug and check the implementation of API that you're using.
You can configure Qt to skip building stuff that you're not interested in.
You can easily patch Qt if there's a bug that you know of a fix for but hasn't been merged into Qt itself yet.
There are downsides too, though. You might run into build issues if you're using configure flags that the CI doesn't use (such as a -no-foo option). It can take a while to build depending on how many submodules you have and what kind of machine you're building on.
In general, if you're not using API that's in dev and not yet released, it's probably not worth bothering.
If you're still interested, this page has instructions for building Qt from Git:
https://wiki.qt.io/Building_Qt_5_from_Git
Is there a hidden setting that will prevent its sources from being modifiable, to stop me from doing this again?
Couldn't you set some permissions on the source directory? I've never had to do this, but have been bitten by it on unrelated occasions before, so I know it works. :D
I'm currently using the maintenance tool to install a newer version of Qt, but other than update or add/remove, there wasn't a re-install option that I could see, am I missing something?
Remove and add is your only option, I think. Otherwise, you can always keep a backup of the source by just copying the whole directory.
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 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.
I'm going through some Meteor tutorials trying to get up to speed, seems like a nice framework. However I'm having difficulty, perhaps because I'm overcomplicating things, with packages. I've installed iron-router and set up some routes, simple enough, apart from that the package is linked to from my projects route rather than being installed into my projects folder structure - I installed with mrt - and iron-router is serving the templates in it's examples folder. Deleting that folder kills the app. Manually installing irk-router into the packages folder for my project and ensuring smart.json is linking to it does nothing to help.
I've ready and searched for hours now but I'm guessing I'm doing something very off the wall as I can't see anyone else with this issue.
Are packages always global in the ./meteorite folder and linked to, or are they local? And if so how do you set them up?
Cheers.
EDIT: After some more tinkering I believe the issue is actually iron-router and not the local install. The app runs but I just have a white screen, I think iron-router is not able to locate my templates.
In the end I removed all the packages, manually deleted anything left over, and re-installed them with Meteorite. That was the only way to fix the problem.
cd /usr/local/meteor/lib/ && npm install <module>
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