Stuck when creating credentials - Yargs through package.json is deprecated - express-gateway

I´m using Windows 10 and following the "Getting started" tutorial, but after creation of user I can´t create the credential for him.
the command line:
eg credentials create -c bob -t key-auth -q
the result:
Configuring yargs through package.json is deprecated and will be removed in the next major release, please use the JS API instead.
Configuring yargs through package.json is deprecated and will be removed in the next major release, please use the JS API instead.
Configuring yargs through package.json is deprecated and will be removed in the next major release, please use the JS API instead.
then I must press Control+C to stop the process.

unfortunately yes, we have a problem with yargs on Windows which is actually tracked in our GitHub repository: https://github.com/ExpressGateway/express-gateway/issues/889
My idea would be to replace yargs with oclif or something modern, but I haven't been able to work on it yet.
Also, I do not have a Windows machine so it is kind of difficult to test it out properly.

Related

eb platform create fails with Ruby SDK deprecated error

When trying to create a custom ElasticBeanstalk platform that uses Python3.10.5, I keep running across this error:
[2022-07-01T05:50:06.466Z] INFO [5419] - [CMD-PackerBuild/PackerBuild/PackerBuildHook/build.rb] : Activity execution failed, because: Version 2 of the Ruby SDK will enter maintenance mode as of November 20, 2020. To continue receiving service updates and new features, please upgrade to Version 3. More information can be found here: https://aws.amazon.com/blogs/developer/deprecation-schedule-for-aws-sdk-for-ruby-v2/
'packer build' failed, the build log has been saved to '/var/log/packer-builder/Python3.10_Ubuntu:1.0.8-builder.log' (ElasticBeanstalk::ExternalInvocationError)
caused by: Version 2 of the Ruby SDK will enter maintenance mode as of November 20, 2020. To continue receiving service updates and new features, please upgrade to Version 3. More information can be found here: https://aws.amazon.com/blogs/developer/deprecation-schedule-for-aws-sdk-for-ruby-v2/
'packer build' failed, the build log has been saved to '/var/log/packer-builder/Python3.10_Ubuntu:1.0.8-builder.log' (Executor::NonZeroExitStatus)
I'm not sure how to get around it, as none of my actual code for this uses ruby at all.
I have tried to SSH into the packer build box and run gem install aws-sdk to get the latest version, however it eventually ends up hanging and never completes.
I'm really unsure of what to do at this point. Any advice?
Update: Was finally able to get a gem install aws-sdk -V to finish after changing the version to ruby2.4, however the problem above still persists.

Updating Loopback 4

I am using Loopback 4 to create a REST-ful API. I'm a mobile developer by trade so typescript et al is all pretty new to me, so please be kind ;)
I created the app using CLI v1.21.4, and saw a message to say that an update is available. I therefore updated my global installation of the CLI. But then when I try and run one of the commands such as lb4 model I see the message:
The project was originally generated by #loopback/cli#1.21.4.
The following dependencies are incompatible with #loopback/cli#1.23.1:
typescript: ~3.5.3 (cli ~3.6.3)
#loopback/authentication: ^2.2.2 (cli ^3.1.1)
I would of course like to take advantage of these newer modules, but I am unsure how to update my app scaffolding and dependencies. Could anyone offer some advice please?
Please check out https://github.com/strongloop/loopback-next/issues/3608:
During lb4 app, we add the cli version to .yo.rc.json, such as:
{
"#loopback/cli": {
"version": "1.21.4"
}
}
lb4 -v lists compatible modules that are released with the cli.
lb4 commands check if the project has incompatible versions with the current cli and prompts users to force or exit.
I would of course like to take advantage of these newer modules, but I am unsure how to update my app scaffolding and dependencies.
The process for updating dependencies is not specific to LoopBack. If you are using npm, then simply run npm update.
Please note that TypeScript often introduces backwards-incompatible changes in semver-minor releases, 3.6 brought few of them. Be prepared to manually fix few compilation errors after the upgrade.
I think that npm update is not going to jump from v2 to v3 for #loopback/authentication, you have to request that upgrade explicitly:
$ npm install #loopback/authentication#latest
There is now a supported update procedure, which is documented here:
https://loopback.io/doc/en/lb4/Update-generator.html
It seems to be simply:
# Ensure you have the latest version of the CLI tool
npm install -g #loopback/cli
# Then ask the tool to check which packages should be upgraded
lb4 update

Is there an easier way to debug ember addons

I have been just starting out with ember addon and one of the difficulty I am facing is to debug it. I have a separate repo for my addon(lets name it my-addon for now), and everytime I make any change, I have to
1) commit it
2) push the changes
3) go to consuming app and then re install the app from git(atleast re-run npm install git:address so I get the latest changes)
4) run ember g my-addon (because I am in older cli)
5) do build
6) and check if things are working
This process is kinda tedious, I was wondering if I can place the addon(all of it) within the consuming app itself, atleast in the dev phase so I can just build my ember app and test the addon in the consuming app itself, and once I feel good about, push it to my local git repo.
Any thoughts or approach on how you folks do it - or may be I am just missing out something and doing it wrong!
Thanks,
Dee
If you use ember-cli you can link your local addon in the consuming app. You can find all details in the user guide
Note that watchman doesn't observe local addon symlinked (there are couple of issues opened both on ember-cli and watchman). I've resolved removing watchman falling back to NodeWatcher (I'm on mac)
I am pretty sure the solution provided by #GUL must work too, but what worked for me was:
1) in the consuming dev app, I created a folder called addons and placed all my addon code there
2) in consuming dev app, in package.json I added :
"ember-addon": {
"paths": [
"addons/ember-chart"
]
}
and that worked for me!
The top answer is best here. I just wanted to offer an alternative that is useful in certain situations. npm pack at root of in development addon. Then cd back to parent project. npm install ../ember-composable-helpers-2.2.0.tgz. And then check if things are working.
npm pack will create a tarball as if published on npm.

Was ember cli 0.2.0-beta.1 released as 0.2.0 resulting in 'SyntaxError: Unexpected token <'?

While trying to figure out how to recreate an ember app which I can't migrate to CLI, and use 'generate' to create resources, and routes with paths and dynamic segments, I was creating and deleting a test app several times. At one point it seems that ember cli tried to update to 0.2.0 and I got warnings about npm packages wanting an older version of node, so I changed the versions in the package json files for those. But when creating a new starter ember app, I get the 'SyntaxError: Unexpected token <' error (update-checker.js, _stream_writable.js, etc).
So I ran 'npm uninstall -g ember-cli' then 'npm install -g ember-cli#0.2.0-beta.1' to get beta back and now I can create starter apps again.
This issue with dependencies being out of line was probably temporary since revisions within CLI are happening so fast. If I came back the next day and cleared out module and component cache and started over, it probably would have cleared up. By reverting CLI manually I wound up with other issues with express live update, so would have to stop and restart express after every edit. I realized I wasn't ready to re-write my gruntfile as a brocfile and deal with all the other issues with migrating to Ember CLI, so started over by updating the Ember dependency in my grunt-based project and going that route, which is also frustrating and hugely problematic, but I'm sure I'm farther along in this route than I would have been in re-writing for Ember CLI.

Travis-CI "The command "bundle exec rake" exited with 1." + mystery 404 error

bundle exec rake runs all tests perfectly fine locally. However, Travis CI keeps blowing up with Problem accessing /authentication without giving much more info to go on. Here's one of the failed builds: https://travis-ci.org/Nase00/Horizon/builds/48094102 For the life of me, I cannot figure out what is causing an authentication error when Travis tries to run bundle exec rake.
Here's the project repo: https://github.com/Nase00/Horizon
I'm not sure what version of Neo4j Travis uses (UPDATE: they use 1.9.4, not supported) but I'm going to guess that it's a bit older than what Neo4j.rb supports. I'm one of the core maintainers and built the Neo4j 2.2 auth support that's fouling you up, but I tested it with different versions, going back to the early 2.1 subversions and had no trouble.
The best practice is to not use Travis's Neo4j at all. Instead, configure Travis to install the same version of the database you're using for dev and production. As a bonus, the rake task that installs Neo also disables auth in 2.2, so you don't have to deal with that at all. It's not that we're against auth, it's that we think of the rake install and config tasks as convenient features for dev/test environment, not production, so no auth seems like a reasonable default.
Take a peak at our .travis.yml file to see how we do the installation. https://github.com/neo4jrb/neo4j/blob/master/.travis.yml. An abstract that'll solve your issue:
script:
- "bundle exec rake neo4j:install['community-2.2.0-M02'] neo4j:start default --trace"
language: ruby
rvm:
- 2.0.0
Swap the community-2.2.0-M02 for whatever version you want to use. I'd have to check again but from what I remember, we are compatible with versions as far back as 2.1.2. I apologize for this not being posted in our docs -- it should be.
I very strongly recommend using Ruby 2.2.0 with Neo4j.rb. We generate a lot of symbols during Cypher queries that won't be garbage collected otherwise.
EDIT for a little more info
The very first thing the auth module does is check for the presence of the authentication REST endpoint. In all of the versions of Neo4j I tested, it didn't give an error like that, it just returned an empty body, which we interpret as a sign that auth is either unsupported or disabled.
Aftermath Edit
Travis support confirmed their provided Neo4j version is 1.9.4.