Every time I try to use an adapter other than sails-disk I'll get a No find() method defined in adapter! Error.
My sails app will lift fine, but when ever I get to a point where the adapter is being called it fails. I've tried several different adapters and they all fail.
I'm using the boilerplate config files.
I had this problem too and only happened with custom adapters. So instead of using the path api/adapters, i moved the adapter to node_modules where others adapters such as sails-mongo are installed, and it did the trick.
usually, you just need to enable your new adapter in yourapp/config/adapters.js
For exemple, with mongo :
add sails-mongo dependence in your package.json file
"dependencies": {
...
"sails-mongo": "~0.9.6"
}
run $ npm install
change your config file (ie: yourapp/config/adapters.js) by editing :
module.exports.adapters = {
'default': 'mongo',
mongo: {
module: 'sails-mongo',
host: 'localhost',
user: '',
password: '',
database: 'your-prod-db'
}
};
Of course for local dev, edit yourapp/config/local.js like:
adapters : {
'default': 'mongo',
mongo: {
module: 'sails-mongo',
host: 'localhost',
user: '',
password: '',
database: 'your-local-db'
}
}
Related
I intend to develop my smart contracts in Hardhat, and to test them on RSK regtest local node. I was able to find a Truffle regtest configuration.
development: {
host: "127.0.0.1",
port: 4444,
network_id: "*"
},
What hardhat.config.js configuration do I need to run my tests on RSK regtest?
To deploy and test your smart contracts on RSK regtest yourhardhat.config.js should look as follows:
/**
* #type import('hardhat/config').HardhatUserConfig
*/
require("#nomiclabs/hardhat-waffle");
module.exports = {
solidity: "0.7.3",
defaultNetwork: "rskregtest",
networks: {
rskregtest: {
url: "http://localhost:4444/",
},
},
};
Then you'll be able to run your tests by typing in the terminal
% npx hardhat test
I have created the nestjs app. In the root app folder I have these subfolders:
dist
migration
src
test
The migration folder contains typeorm migrations.
When run application with npm run start:dev I have this error:
import {MigrationInterface, QueryRunner} from "typeorm";
^^^^^^
SyntaxError: Cannot use import statement outside a module
at Module._compile (internal/modules/cjs/loader.js:891:18)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:991:10)
at Module.load (internal/modules/cjs/loader.js:811:32)
at Function.Module._load (internal/modules/cjs/loader.js:723:14)
at Module.require (internal/modules/cjs/loader.js:848:19)
at require (internal/modules/cjs/helpers.js:74:18)
at Function.PlatformTools.load (C:\Users\dakru1\Documents\employo\employo-api\node_modules\typeorm\platform\PlatformTools.js:114:28)
at C:\Users\dakru1\Documents\employo\employo-api\node_modules\typeorm\util\DirectoryExportedClassesLoader.js:39:69
at Array.map (<anonymous>)
at Object.importClassesFromDirectories (C:\Users\dakru1\Documents\employo\employo-api\node_modules\typeorm\util\DirectoryExportedClassesLoader.js:39:10)
I understand the error message and I know how to fix it when it relates to application's code.
However, my problem is that this error come from typeorm migration file: [app-root-folder]\migration\1587067680466-Init.ts which shouldn't be used when application runs.
Why nestjs uses migration files. How can I ignore migration folder when running nestjs app?
to solve it just put the following code on your "scripts" at package.json:
"typeorm": "ts-node-dev ./node_modules/typeorm/cli.js",
After that you'll be able to run your typeorm migration:run :)
I found the solution:
This happends to me because I was using Nest and when you run the command nest start, under the hood, Nest executes node and tsc and node commands and because of that you need your files to be in JavaScript format. So, as the migrations are generated in Typescript... the statement import gives the error because is only for TypeScript.
The only thing i did to solve it is this:
migrations: ["dist/migrations/*.js"],
This is telling TypeOrm that search for the migration in the dist directory where all the JavaScript code was compiled previously.
Of course in my tsconfig.json file the output dir is pointing to dist.
"outDir": "./dist",
I had the same issue. I did the following as a workaround:
Set your ormconfig.json to look for migrations files with only js suffix:
"migrations": ["migrations/*.js"],
Install typescript globally: npm install -g typescript
After generating your migration, transpile typescript files to javascript files with typescript command:
tsc migrations/migration-file.ts
Run your migration: npm run typeorm migration:run
You can now run your application: npm run start:dev
I know this question is old, but I just came across it because I had the same problem. I was able to solve it by adding "migration/**/*.ts" to the "exclude" array in the /tsconfig.build.json file like so:
{
"extends": "./tsconfig.json",
"exclude": ["node_modules", "test", "dist", "**/*spec.ts", "migration/**/*.ts"]
}
The same issue here, and in my case the root cause was a wrong migrations path in the connection configuration, like this;
const databaseConfig: ConnectionOptions = {
name: 'default',
type: 'postgres',
host: process.env.TYPEORM_HOST || '',
port: Number(process.env.TYPEORM_PORT),
username: process.env.TYPEORM_USERNAME || '',
password: process.env.TYPEORM_PASSWORD || '',
database: process.env.TYPEORM_DATABASE || '',
logging: false,
synchronize: false,
entities: [],
migrations: ['src/migrations/*.ts'],
};
Instead, I have changed it to
const migrationPaths: string[] = process.env.TYPEORM_USE_CLI === 'true' ? ['src/migrations/*{.ts,.js}'] : [];
const databaseConfig: ConnectionOptions = {
name: 'default',
type: 'postgres',
host: process.env.TYPEORM_HOST || '',
port: Number(process.env.TYPEORM_PORT),
username: process.env.TYPEORM_USERNAME || '',
password: process.env.TYPEORM_PASSWORD || '',
database: process.env.TYPEORM_DATABASE || '',
logging: false,
synchronize: false,
entities: [],
migrations: migrationPaths,
};
another test you can try to see if the problem is really with migration is to move the migration filter out of src.
For TypeORM v0.3.0 or higher, glob patterns in migrations are DEPRECATED. It is recommended to directly include the migration classes.
entities, migrations, subscribers options inside DataSourceOptions accepting string directories support is deprecated. You'll be only able to pass entity references in the future versions.
import { DataSource, DataSourceOptions } from 'typeorm';
import { CreateUser1669370712331 } from '../../migrations/1669370712331-CreateUser';
import { UserModify1669457039074 } from '../../migrations/1669457039074-UserModify';
import { User } from '../users/entities/user.entity';
export const config: DataSourceOptions = {
type: 'sqlite',
database: 'db/database.sqlite',
logging: true,
synchronize: false,
entities: [User],
migrations: [CreateUser1669370712331, UserModify1669457039074],
};
I am running an WebDriver.io test using gulp-wdio npm pakage
on selenium-standalone
The Code that I run in gulp is:
gulp.task('e2e', function () {
return gulp.src('wdio.conf.js')
.pipe(wdio({
wdio: {
specs: './test/features/**/*.feature'
}
}));
});
And my wdio.conf.js define browsers this way:
capabilities: [
{
browserName: 'internet explorer',
version: 'ANY'
}
],
How ever the typing is very slow, i had found on the internet that running 32 bit version of the web-driver resolves the issue, how ever I can't find how to configure the capabilities or some other place to run the IE32 bit driver by default...
Any help will be appreciated #:-)
After 2 days of research I had found the solution !!!
There is a configuration file that need to be supplied to the selenium standalone
as shown in this Example
so our final setup is done in this way:
We have a configuration file called wdio.browsers.setup.js that contains the browsers setup:
module.exports = {
baseURL: 'https://selenium-release.storage.googleapis.com',
version: '3.3.1',
drivers: {
chrome: {
version: '2.29',
arch: process.arch,
// - Recent versions of the driver: https://sites.google.com/a/chromium.org/chromedriver/
baseURL: 'https://chromedriver.storage.googleapis.com'
},
ie: {
version: '3.0.0',
arch: 'ia32',
// - Recent versions of the driver: http://selenium-release.storage.googleapis.com/index.html
baseURL: 'https://selenium-release.storage.googleapis.com'
},
firefox: {
version: '0.15.0',
arch: process.arch,
baseURL: 'https://github.com/mozilla/geckodriver/releases/download'
}
}
};
and then inside wdio.conf.js we load it and assign to a special parameters
let browsersSetup = require('./wdio.browsers.setup');
exports.config = {
seleniumArgs: browsersSetup,
seleniumInstallArgs: browsersSetup,
After that all is working fine #:-)
Note: if you have your web-driver installed globally remove the global setup first it's located in:
C:\Users\%USERNAME%\AppData\Roaming\npm
Then you can run the local installation using:
./node_modules/.bin/selenium-standalone install --config=../../wdio.browsers.setup.js
Please find the below working solution for IE browser to install 32 bit:
services: ["selenium-standalone"],
seleniumArgs: {
drivers: {`enter code here`
ie: {
version: "3.4.0", // or whatever latest is
arch: "ia32", // forces use of 32 bit driver
baseURL: "https://selenium-release.storage.googleapis.com"
},
},
},
seleniumInstallArgs: {
drivers: {
ie: {
version: "3.4.0", // or whatever latest is
arch: "ia32", // forces use of 32 bit driver
baseURL: "https://selenium-release.storage.googleapis.com"
},
},
},
I created a REST service in node js and wrote the test cases using mocha. I have been able to generate the code coverage using istanbul and is working absolutely fine. Now my requirement is to show the code coverage using Sonar. The code compliance violations are getting listed as expected. But the code coverage is not getting generated in sonar. I doubt there is something wrong with the gruntfile.js configuration. Currently, I generate the code compliance violation by copying the source inside the grunt-sonar-runner folder within node_modules and execute grunt-sonar-runner. My current folder structure is as shown below :
<ProjectRoot>
|--server.js
|--[test]
|--|--serverTest.js
|--[node_modules]
|--|--[grunt-sonar-runner]
|--|--|--[src]
|--|--|--|--server.js
In the gruntfile.js,
grunt.initConfig({
jshint: {
all: [
'Gruntfile.js',
'tasks/*.js',
'test/*.js'
],
options: {
jshintrc: '.jshintrc'
}
},
// Before generating any new files, remove any previously-created files.
clean: {
tests: ['tmp']
},
// Configuration to be run (and then tested).
sonarRunner: {
analysis: {
options: {
debug: true,
separator: '\n',
sonar: {
host: {
url: 'http://localhost:9000'
},
jdbc: {
url: 'jdbc:h2:tcp://localhost:9092/sonar',
username: 'sonar',
password: 'sonar'
},
projectKey: 'sonar:grunt-sonar-runner:0.1.0',
projectName: 'Grunt Sonar Runner',
projectVersion: '0.10',
sources: ['src'].join(','),
language: 'js',
sourceEncoding: 'UTF-8'
}
}
},
dryRun: {
options: {
dryRun: true,
debug: true,
separator: '\n',
sonar: {
host: {
url: 'http://localhost:9000'
},
jdbc: {
url: 'jdbc:mysql://localhost:3306/sonar',
username: 'sonar',
password: 'sonar'
},
projectKey: 'sonar:grunt-sonar-runner:0.1.0',
projectName: 'Grunt Sonar Runner',
projectVersion: '0.10',
sources: ['src'].join(','),
exclusions: '**/R.js'
}
}
}
},
// Unit tests.
mochaTest: {
test: {
options: {
reporter: 'spec'
},
src: ['test/**/*.js'],
}
}
});
we have two sections --> analysis and dryRun. What is this dryRun ?
Just outside that, we have a key called mochaTest.
While running mocha with istanbul, I am getting coverage reports generated in the project root inside a folder called coverage. Unfortunately it is not getting listed in sonar. Any help would be appreciated.
Thanks in Advance,
Noble
Just had to define a sonar-roject.properties in the project root folder. Inside that properties file, we can specify the relative path to the lcov.info generated by istanbul. After starting up the sonar qube server, just run sonar-runner (provided sonar runner is present in the system path). Sonar reports will be visible in sonar dashboard
I have a project where Intern unit tests are supposed to be in a different directory tree than the source code under test. Somewhat like this:
projectRoot
projectRoot/src
projectRoot/tests
projectRoot/tests/intern.js
projectRoot/tests/node_modules/intern
projectRoot/tests/MyTestSuite.js
In the Intern configuration file, I define an AMD package that uses relative paths with ../ to reach src from the unit test suites. Here's an example configuration:
define({
environments: [ { browserName: 'chrome', platform: 'WINDOWS' }],
webdriver: { host: 'localhost', port: 4444 },
useSauceConnect: false,
loader: {
packages: [
{ name: 'testSuites', location: '.' },
{ name: 'externalDep', location: '../src' }
]
},
suites: [ 'testSuites/MyTestSuite' ]
});
And a matching unit test suite
define([ "intern!tdd", "intern/chai!assert","externalDep/ExternalDep"],
function(tdd, assert, ExternalDep) {
tdd.suite("Suite that has external dependency", function() {
tdd.test("Test if external dependency is loaded correctly", function() {
assert(ExternalDep === "hello");
});
});
}
);
This works fine when tested directly in the browser (client.html) or node (client.js). When fired off through a Selenium Server (with runner.js), however, the client.html running in the browser started by Selenium can't find the external dependencies. In the above example, it tries to request ExternalDep at http://localhost:9000/__intern/src/ExternalDep.js, which is a 404 because the src directory is not within intern.
I suppose that if I put intern.js at the highest common super-directory of both the tests and the source code, it would work. But our project is currently set up in a way which makes that impractical. Is there a way for configuring sources that live beyond the location of the Intern config file, or did I just make a silly mistake?
Thanks!
There is no problem putting the tests in a different directory from the rest of the code, but projectRoot needs to be the working directory from which you start the runner, and you need to change your loader configuration to match.
So, instead of right now where you are starting Intern from projectRoot/tests like this:
…/projectRoot/tests$ ./.bin/intern-runner config=intern
you need to start it from projectRoot:
…/projectRoot$ ./tests/.bin/intern-runner config=tests/intern
…and change your loader configuration:
loader: {
packages: [
{ name: 'testSuites', location: 'tests' },
{ name: 'externalDep', location: 'src' }
]
},