As far as I can tell, the point of meteorite is to simplify dealing with which versions of plugins and branch of meteor your project needs. But I don't want to follow the churn on a branch of meteor; I want to use a stable version. It seems as if this should be possible. How do I do it?
You can specify alternate branches and forks respectively:
{
meteor: {
"branch": "devel",
"git": "https://github.com/meteor/meteor.git"
}
}
Per the documentation:
The meteor specification is not required. Meteor's public repo checked out to the master branch is the default. You can specify meteor.branch and meteor.git to use alternate branches and forks respectively.
To use a stable version, simply omit the meteor section from the smart.json file altogether and you'll use the most recent, stable version.
Use tag to choose a particular Meteor version:
"meteor": {
"git": "https://github.com/meteor/meteor.git",
"tag": "release/0.6.3.1"
},
(See --tag in http://oortcloud.github.com/meteorite/)
Related
On my package.json file I have the following below. As expected it is installing version 16.x but I would like it to only install the latest 12.x. Is there a way to setup the app to only do that?
"engines": {
"node": ">=12.19.0"
},
If I understand your question correctly, you should be able to just use 12.x in your package.json. (Heroku Docs/NPM Docs)
"engines": {
"node": "12.x"
}
You can use NPM's semver syntax to define supported versions. If you only want versions greater than 12.19.0 but still within 12.x, you can use ^12.19.0.
Looks like Cloud Functions does not support Async-Await notation. Is there a way I could use Babel until they do or is it recommended to use promises?
My current function that sits on Node is like so:
exports.getToken = async (req, res) => {
//1. Generate token from Braintree
const result = await gateway.clientToken.generate();
//2. Return the client token
res.json(result.clientToken);
};
Cloud Functions runs the LTS version of node.js, which according to the documentation is 6.14.0 at this moment in time. node 6.x supports EcmaScript 6, which does not include async/await.
However, you can write your code in TypeScript and have that transpiled down to ES5/ES6, which will effectively convert the use of async/await into promises. A web search suggests that perhaps this plugin can be used to help Babel with similar transpiling.
It's worth noting that the Firebase CLI now allow you to initialize a new Cloud Functions project with native TypeScript support, which is what the Firebase team is currently recommending to developers.
If you don't want to use TypeScript, you can now also choose node 8 (which is currently in beta, and does support async/await for plain JavaScript) as a deployment target. You can follow the documentation to edit your package.json to indicates that your functions should be deployed to node 8.
Now you can use Node.js version 8 by adding this in your functions/package.json:
"engines": {
"node": "8"
}
Example: https://github.com/firebase/functions-samples/blob/Node-8/authenticated-json-api/functions/package.json
Instead of transpile TypeScript, I have transpiled my javascript after follow this very nice post and take a look at this repository
Basically you can do:
npm install -g #babel/cli #babel/core #babel/preset-env
UPDATE:
I'm having troubles with version "7.0.0-beta.51" of babel. "7.0.0-beta.44" still ok.
Switch to stable version 6
npm install --save-dev babel-cli babel-preset-env
Create the file .babelrc inside your project folder
{
"presets": [
["#babel/env", {
"targets": {
"node": "6.11.5"
}
}]
]
}
Move your "functions" folder to "firebaseFunctions" folder and then run
babel firebaseFunctions --out-dir functions --copy-files --ignore firebaseFunctions/node_modules
Or run this command for each files you want to transpile
babel originalfile.js --out-file transpiledfile.js
The above solutions didn't work for me alone. I had to update to the latest firebase tools:
npm update -g firebase-tools
and then update my package.json with adding:
"engines": {"node": "8"}
and everything worked fine with async/await.
Credits to this blog https://howtofirebase.com/cloud-functions-migrating-to-node-8-9640731a8acc
In your functions/.eslintrc.json file set as 'ecmaVersion': 2017
this will remove eslint syntax error
"parserOptions": {
"ecmaVersion": 2017
},
In your functions/package.json file set node version to 8 by adding below
"engines": {
"node": "8"
},
this will update the cloud node version to 8 default node version is 6
as #adam said, solved my problem to reinstall/upgrade the global firebase package
the difference is in my case was using NVM (node version manager).
Somehow, my default node(v13.x) had the firebase-tools but i didnt installed globally at project node (v10/8)
so first:
nvm use 10
then:
npm i -g firebase-tools
reinstalling at correct node version got my async functions working properly.
This may (should) have been asked before somewhere but I can't seem to find an answer. If someone provides a link I can delete this post!:
Just trying to get my head around some of composer's (probably applies to other package managers too) functionality.
Basically I just want to know what composer does in the following scenarios:
1.
My main project has a dependency:
"guzzlehttp/guzzle": "5.0.*",
My external bundle has a dependency on
"guzzlehttp/guzzle": "5.0.*",
Does composer install guzzlehttp/guzzle one time because it knows it only needs it once?
2.
Same scenario but in the future if someone updates the main project to use:
"guzzlehttp/guzzle": "6.0.*",
Will composer now install 2 versions of guzzle (5 and 6) (I presume this is what it should do), or will it take the highest version (i.e. 6)? Also if there are 2 versions will this cause any conflicts because namespaces might be the same?
Thanks
To question 1
Yes Composer can only install one version of each extension/package.
To question 2
Because of answer 1: Composer would consider your main project and the external package as incompatible.
In this case you could
stay with version 5 at your main project too.
ask the external package owner to upgrade to version 6 too if it's compatible to.
fork the external package and make it compatible to version 6 yourself
We had a situation today where we were using multiple libraries, and one used Guzzle v5 and the other Guzzle v6. Upgrading (or downgrading) was not a viable option, as it was third party code, so we had to be able to install both versions of Guzzle.
Here's what we did. This is a TOTAL FRACKING HACK, and I'd advise doing this only as an absolute last resort. It works, but updating your calling code to use just one version is a much better option.
The trick is that you need to re-namespace one of the two versions. In our case we decided to change v6 to GuzzleHttp6. Here's how to do that:
Make sure your composer.json has v6 enabled:
"require": {
"guzzlehttp/guzzle": "^6.2"
// possible other stuff
},
composer install to get Guzzle v6 all its dependencies installed.
Move the /vendor/guzzlehttp directory over to a new /vendor-static/guzzlehttp directory.
Do a case-sensitive find & replace on the /vendor-static directory to replace GuzzleHttp with GuzzleHttp6. This effectively brings the Guzzle 6 code into a new namespace.
Now update your composer.json to include Guzzle's own dependencies manually, and then autoload the code in the /vendor-static folder. Note you'll want to REMOVE the main guzzle require statement (or change it include guzzle 5);
"require": {
"guzzlehttp/guzzle": "~5",
"psr/http-message": "~1.0",
"ralouphie/getallheaders": "^2.0.5"
},
"autoload": {
"files": ["vendor-static/guzzlehttp/guzzle/src/functions_include.php",
"vendor-static/guzzlehttp/psr7/src/functions_include.php",
"vendor-static/guzzlehttp/promises/src/functions_include.php"],
"psr-4": {
"GuzzleHttp6\\": "vendor-static/guzzlehttp/guzzle/src/",
"GuzzleHttp6\\Psr7\\": "vendor-static/guzzlehttp/psr7/src/",
"GuzzleHttp6\\Promise\\": "vendor-static/guzzlehttp/promises/src/"
}
},
composer update to remove the old Guzzle v6, and install Guzzle v5. This will also install the psr/http-message and ralouphie/getallheaders dependencies.
You may need to do a composer dump-autoload to force the autoloader to add the new include paths. In theory this should happen on composer update but I had to force it.
Now update your calling code; instead of calling \GuzzleHttp, you'll call \GuzzleHttp6 .
And that's it. You should be able to run both concurrently. Note that whatever version of Guzzle v6 you've got in the /vendor-static directory will be there forever-more, so you may want to update that from time-to-time.
I was prompted to update my meteor from 0.5.4 to 0.6.1 today and when I updated I lost all of the code I had created earlier in the day. I tried using meteor --release 0.5.4 to get back to the previous version but I get the error message "unknown release" this was the release I had before.
Has anyone else had this issue and if so, how did you resolve it?
Thank you for your help!
Judy
"meteor --release x.y.z" will only work with releases >= 0.6.0. So you can go back to 0.6.0 using that mechanism but not anything earlier than 0.6.0.
If you want to use an earlier release. You can edit smart.lock (smart.lock exists if you are using meteorite. If you are not using meteorite I'm not sure how easy it is to switch between releases of meteor) and change the commit property for meteor to use the commit for 0.5.4. It should be commit: 2d27799008fb87a06d4119c48097aa382d230b61
So you should have this is your smart.lock:
"meteor": {
"git": "https://github.com/meteor/meteor.git",
"branch": "master",
"commit": "2d27799008fb87a06d4119c48097aa382d230b61"
}
I think updating Meteor might have broken my app. It was working, then I ran meteor update, and now it is not working. Can I do something like meteor downgrade?
Meteor 0.6.0 and above ships with a new distribution system. You can now pass the --release argument to any Meteor command and it will run against the requested release. For example, to bundle your app against Meteor 0.6.1, run: meteor bundle --release 0.6.1. Notably, this only works for post-0.6.0 releases.
If you want to pin your app to a specific release, run: meteor update --release <release>. This modifies the .meteor/release file in your app directory. Then simply run Meteor as usual. You'll still get notified when there's a new release available.
UPDATE: As of Meteor 0.6.0, this functionality is available without using Meteorite. See Avital's answer. (for versions > 0.6.0. To use functionality on versions less than 0.6.0 you can still use Meteorite:
If you want to control versions with your apps (so your existing app can still use an older version, or 0.57.1 (with the security bug fix) you can use meteorite: https://github.com/oortcloud/meteorite
Install it via npm install -g meteorite
Its also helpful with loads of other packages from http://atmosphere.meteor.com.
To control the version of your app edit your smart.json to something with:
{
"meteor": {
"tag": "v0.5.7"
}
}
Only the app you've already made will be affected & you can upgrade it when you're ready.
I have tried this and it is very hard. My best advice is to try and copy all the files from an app running the version you want, then paste your app's code in there.
There is no meteor downgrade command from its CLI. The best and easy way if you have version control like GIT, just undo your recent changes by git stash save, and run meteor again.
On Windows, I was able to effectively "downgrade" from a failed upgrade by editing the version number to a previous working release in the file:
C:\Users\Paul\AppData\Local.meteor\meteor.bat
You need to change it to a version which has a corresponding folder in: .meteor\packages\meteor-tool