Problems with behat + mink - kohana

I'm trying to install behat + mink (on kohana framework, not symfony, I'm putting behat into the modules folder - I'm writting this just in case, but I guess that's not what causes my problem).
I am having the same search.feature file as it is in behat documentation, I'm changing features/bootstrap class into the:
<?php
use Behat\Behat\Context\ClosuredContextInterface,
Behat\Behat\Context\TranslatedContextInterface,
Behat\Behat\Context\BehatContext,
Behat\Behat\Exception\PendingException;
use Behat\Gherkin\Node\PyStringNode,
Behat\Gherkin\Node\TableNode;
use Behat\MinkExtension\Context\MinkContext;
/**
* Features context.
*/
class FeatureContext extends MinkContext
{
}
And when I type "behat" in the CLI I get the following error: Call to a member function getSession() on a non object in .....RawMinkContext.php on line 80.
I've read somewhere that it's the behat.yml file which causes this error. I think the right thing to do is to create new behat.yml file in the root of the installed behat folder and put this code inside:
default:
extensions:
Behat\MinkExtension\Extension:
base_url: http://wikipedia.org
goutte: ~
selenium2: ~
paths:
features: features
bootstrap: features/bootstrap
annotations:
paths:
features: features/annotations
closures:
paths:
features: features/closures
But of couse it gives me the same error. I've tried a lot of configurations: copying only extensions part, changing default into context, copying the same content into three other behat.yml files (vendor/behat/behat, and vendor/behat/monk, and vendor/behat/monk-ententions) - none works.
Can someone tell me what's the right way to set this? Maybe someone here also had problems with that...
BTW. When I installed behat withough goutte, only with selenium2 driver, I was getting errors that goutte is not installed. But when I installed it with goutte, I was getting errors that there's no fabpot/goutte directory (or fapbot/, I don't remember, but I guess it was the first one :D), so I deleted everything and reinstalled behat with the following composer.json file, maybe this also has something to do with this error:
{
"name": "behat/mink-browserkit-driver",
"description": "Symfony2 BrowserKit driver for Mink framework",
"keywords": ["Symfony2", "testing", "browser"],
"homepage": "http://mink.behat.org/",
"type": "mink-driver",
"license": "MIT",
"authors": [
{
"name": "Konstantin Kudryashov",
"email": "ever.zet#gmail.com",
"homepage": "http://everzet.com"
}
],
"require": {
"php": ">=5.3.1",
"symfony/browser-kit": ">=2.0.0,<2.2.0",
"symfony/dom-crawler": ">=2.0.0,<2.2.0",
"behat/behat": "2.4.*#stable",
"behat/mink": "1.4.*#stable",
"behat/mink-extension": "*",
"behat/mink-goutte-driver": "*",
"behat/mink-selenium2-driver": "*"
},
"minimum-stability": "dev",
"autoload": {
"psr-0": {
"Behat\\Mink\\Driver": "src/"
}
},
"config": {
"bin-dir": "bin/"
}
}

The recommended way to install Behat+Mink for anything, not just Kohana, is via Composer. See http://docs.behat.org/quick_intro.html for instructions. The autoload clause you have in your composer.json is not required.
As for your modules attempt, KO3.2 does not yet have the ability to load PSR-0 and so putting it in modules will not allow it to be loaded correctly.
Don't randomly copy your behat.yml - you only need one copy in your project root. If you are worried, you can explicitly load your behat.yml via bin/behat -c /path/to/behat.yml
With your composer.json set up correctly to have mink dependencies, you can then just do bin/behat -dl to verify mink works.
You can then do bin/behat --init to create your features filestructure.
This will create a FeatureContext which overrides Mink's definitions, so add
require_once __DIR__.'/../../vendor/autoload.php';
and change the class definition to:
class FeatureContext extends Behat\MinkExtension\Context\MinkContext
in your features/bootstrap/FeatureContext.php file.
Everything should work as expected now. I recently did a Behat+Mink+KO3 setup, feel free to see how I did it here: https://github.com/Moult/Eadrax/commit/b5dd813c92b82aea29eea13b5a30bae170aa57e6

Related

Yarn workspaces -- package alias

TL;DR How can I create an alias for a local yarn workspace dependency?
I've tried yarn workspaces before and never succeeded, and I'm giving it another try.
I've set "workspaces": ["packages/*"] in package.json.
For each package, I decided to use the naming convention #-/package-name to prevent naming conflicts and without worrying about having namespaces for internal packages.
When adding packages as dependencies, I've been following a style where I use an interface name for resolution, but point that towards a concrete implementation. This is what I did before using yarn workspaces:
"dependencies": {
"my-interface-name": "file:some/path/to/packages/some-concrete-implementation"
}
This is basically to allow what I like to call compile-time static dependency injection. And it also means each package can individually name their interface dependencies appropriately to their need and to prevent naming conflicts.
However, I can't figure out how to accomplish this with yarn workspaces. How do I create an alias for my yarn workspaces package #-/some-concrete-implementation called my-interface-name?
What I've already tried with no success:
Defining the dependency like "my-interface-name": "#-/some-concrete-implementation"} - for some reason this causes yarn to look for #-/some-concrete-implementation on the npm registry instead of in the local workspace
I've also tried to use the workspace protocol: "my-interface-name": "workspace:#-/some-concrete-implementation"} but it still looks for the package on the npm registry!
What I haven't yet tried and could work but removes benefits of using yarn workspaces in the first place:
"dependencies": {"my-interface-name": "file:../../node_modules/#-/some-concrete-implementation"}"
Have you seen the resolutions package.json key? Is it what you need?
I've used it for aliasing/overriding external packages but the example in the docs shows it working with local packages.
Resolutions
Allows you to override a version of a particular nested dependency. See the Selective Versions Resolutions RFC for the full spec.
{
"resolutions": {
"transitive-package-1": "0.0.29",
"transitive-package-2": "file:./local-forks/transitive-package-2",
"dependencies-package-1/transitive-package-3": "^2.1.1"
}
}
From the RFC:
"**/a" denotes all the nested dependencies a of the project.
"a" is an alias for **/a (for retro-compatibility, see below, and because if it wasn't such an alias, it wouldn't mean anything as it would represent one of the non-nested project dependencies, which can't be overridden as explained below).
So, I believe the rule you need is:
"**/my-interface-name": "file:some/path/to/packages/some-concrete-implementation"
// OR equivalent
"my-interface-name": "file:some/path/to/packages/some-concrete-implementation"
I believe it works in the package's package.json. Worst case you can hoist it to the workspace root and make the rule specific to the workspace e.g. "a/b".
The workspace: alias protocol (available in pnpm too) seems the direction to take.
I've also tried to use the workspace protocol: "my-interface-name": "workspace:#-/some-concrete-implementation"} but it still looks for the package on the npm registry!
Be sure to have yarn 3 installed, otherwise you'll run into weird issues.
Note that the syntax of "my-interface-name": "workspace:#-/some-concrete-implementation" looks incorrect.
It should be "#xxx/some-concrete-implementation": "workspace:*", assuming the name of linked the package is "name": "#xxx/some-concrete-implementation".
With this in mind you don't even need to create a specific #-/name. With workspace protocol, yarn will ensure it's never downloaded from npm. It becomes an internal workspace dependency.
PS:
Yarn 3 installation
Generally a simple yarn set version 3.0.2 && yarn plugin import workspace-tools) will work.
To avoid pnp current limitation, check the generated config .yarnrc.yml and ensure nmLinker is set to 'node-modules'
# Yarn 2+ supports pnp or regular node_modules installs. Use node-modules one.
nodeLinker: node-modules
plugins:
- path: .yarn/plugins/#yarnpkg/plugin-workspace-tools.cjs
spec: "#yarnpkg/plugin-workspace-tools"
yarnPath: .yarn/releases/yarn-3.0.2.cjs
PS: you might want to add this to .gitignore too
.yarn/*
!.yarn/patches
!.yarn/releases
!.yarn/plugins
!.yarn/sdks
!.yarn/versions
.pnp.*
Run a yarn install just after.
About package.json's
Like you did, the root package.json will define the workspace paths:
{
"name": "monorepo",
"workspaces": [
"packages/*" // Enable package discovery in packages/* directory.
],
// ...
"devDependencies": {
"husky": "7.0.2", // Only what's needed for monorepo management
}
In your app packages/app/package.json
{
"name": "my-app",
"devDependencies": {
"#types/node": "16.10.1",
//...
},
"dependencies": {
// Assuming the name of packages/shared is "#your-org/some-concrete-implementation",
// we explicitly declare the dependency on it through
// workspace: alias (package-manager perspective)
"#your-org/some-concrete-implementation": "workspace:*",
}
}
You consumed package should declare the same name
{
"name": "#your-org/some-concrete-implementation",
}
Bonus: Typescript aliases
If your project is written in ts, you can even replicate your paths through
typescript path mapping. It will allow to include the files just as is (no prior compilation needed).
Following your example, just edit a ./packages/xxx/tsconfig.json in this way
{
"compilerOptions": {
// here baseUrl is set at ./src (good practice), can
// be set to '.'
"baseUrl": "./src",
"paths": {
// Declare deps here (keep them in sync with what
// you defined in the package.json)
// PS: path are relative to baseUrl
"#your-org/some-concrete-implementation/*": ["../../some-concrete-implementation/src/*"],
// if you have a barrel in ui-lib
"#your-org/some-concrete-implementation": ["../../some-concrete-implementation/src/index"],
}
},
}
PS: for non typescript: babel/plugin-module-resolver can be used in a similar manner.

Trying to share code from Hyperapp with Bit.dev

I'm trying to share my code from my front (hyperapp) to my admin (hyperapp to) to make "preview" button.
The setup of these projects was made by an other dev, so i had to learn hyperapp workflow on the job, i'm not expert.
From what i know he was inspired by Facebook React conf.
All my usefull code is in src/ folder, and there is many dependencies so i have to export all (api, constants, utils, etc..).
Here is my bit configuration (that work, it export code correctly):
"bit": {
"env": {
"compiler": "bit.envs/compilers/react#1.0.2"
},
"packageManager": "yarn",
"packageManagerArgs": [
"--production",
"--no-optional"
],
"packageManagerProcessOptions": {
"shell": true
},
"resolveModules": {
"modulesDirectories": [
"src"
]
},
"dist": {
"entry": "src",
"target": "dist"
}
}
So, the code is "correctly" exported to bit.dev, but, when i import it from my admin with
"#bit/adrienbelair.betterise-web.modules": "^0.3.0",
i get the following error after running yarn:
yarn install
ls: Command failed.
Exit code: 1
Command: node .bit.postinstall.js
...
Error: ENOTDIR: not a directory, mkdir 'node_modules/utils/HOA'
Yes, if i look into node_module, utils is a file, and not a directory
All these are auto-generated, i dont understand what am i doing wrong?
Second thing, probably from this above error, when i try to import a component (even if there is an error, vendor are downloaded and at their place), i get:
import { Advice } from '#bit/adrienbelair.betterise-web.modules/dist/modules';
./node_modules/#bit/adrienbelair.betterise-web.api/controlleur.js
Module not found: Can't resolve 'api' in '/Users/prinzivalle/Web/betterise/admin-front/node_modules/#bit/adrienbelair.betterise-web.api'
From this line (if i look into node_module, where the error is thrown):
import { User, Cardline } from 'api';
I know, its a very specific case, mine, but i dont find any forum or explicit tutorial. Only some little component export with not a lot of dependencies.
I made my code with a little knowledge of Hyperapp/React and without thinking about sharing it one day..
Thank for reading.

Is there a way to ignore test files for eslint-plugin-security?

With a node.js project, I've added eslint-plugin-security and it is giving a lot of warnings for code in my test/spec files (using mochajs). Since the test code won't be running in production, these don't seem as useful as they do in the project's actual code. (A lot of Generic Object Injection Sink warnings )
Is there a way to have the security plugin ignore certain files other than putting /* eslint-disable */ at the top of every spec file?
The best way I found to deal with this case is based on this answer.
You can override parts of your eslint file in a subfolder. In my case I'm disabling problematic rules from a jest plugin inside my e2e tests folder. Example .eslintrc.js in /e2e-tests/ :
module.exports = {
overrides: [
{
files: ["*.spec.js"],
rules: {
"jest/valid-expect": 0
}
}
]
};
There is three way to ignore files or folders:
1. Creating a .eslintignore on your project root folder with the thing you want to ignore:
**/*.js
2. Using eslint cli & the --ignore-path to specify another file where your ignore rules will be located
eslint --ignore-path .jshintignore file.js
3. Using your package.json
{
"name": "mypackage",
"version": "0.0.1",
"eslintConfig": {
"env": {
"browser": true,
"node": true
}
},
"eslintIgnore": ["*.spec.ts", "world.js"]
}
Official Documentation
On my side, I had issue with Intellij IDEA where eslint was checking files in a folder only dedicated to Typescript (+tslint) which was a pain, so I've picked solution 3.

shimming linkurious - how to configure?

I'm trying to use the linkurious library (a sigma fork), which provides a "main": "dist/sigma.require.js" (in the package.json). this allows me to do:
var sigma = require('linkurious');
however, the plugins are not included so I have to require them separately. the problem is that the plugins rely on the sigma variable being available in the global scope. so I've shimmed things as follows (from the package.json):
"browser": {
"sigma": "./node_modules/linkurious/dist/sigma.js",
"linkurious/plugins": "./node_modules/linkurious/dist/plugins.js"
},
"browserify-shim": {
"sigma": {"exports": "sigma"},
"linkurious/plugins": { "depends": [ "sigma" ] }
},
"browserify": {
"transform": [ "browserify-shim" ]
},
which, when run in a browser doesn't generate errors during inclusion of the plugins (I gather this means the global variable is available) but references to the plugins fail (as if they failed to attach themselves, or attached themselves to a non-global variable).
I'm using grunt-browserify to run the process where I have it configured like this (from the Gruntfile.js):
grunt.initConfig({
browserify: {
libs: {
files: { 'inc.js': ['index.js'] },
},
}
});
I've attached a little project to this issue with the minimal required code to demonstrate the problem in the hopes that someone else can replicate/figure out. unpack, type npm install; npm start and run a browser against http://localhost:8002/ to see the issue.
thanks in advance,
ekkis
sigma.zip
- edit I -
incidentally, bendrucker at the git repo (see: https://github.com/thlorenz/browserify-shim/issues/215) suggests I need to do a global transform. It's been explained to me that shimming doesn't work on node_modules files and for those I need a global transform. this doesn't make much sense to me as the whole point of shimming is that you don't own the code you're shimming. in any case, bendrucker pointed me to this other SO post where the question is posed but no answers are provided.
help?

getting browserify-shim to work as expected

I am trying to get browserify-shim to work, but I can't seem to get it to create the globals I expect to see.
(note, my end goal is to get this working from gulp, but after having many problems, I figured I would eliminate one variable and try to get this working in browserify alone)
In this case, I expect "horses" to be created as a global variable pointing to the jQuery library.
// package.json
{
"version": "0.0.1",
"browser": {
"jquery": "./lib/js/vendor/jquery-2.0.2.js"
},
"browserify": {
"transform": [
"browserify-shim"
]
},
"browserify-shim": {
"jquery": "global:horses"
},
"devDependencies": {
// my dev dependencies
},
"dependencies": {
// my production dependencies
}
}
With this configuration, from the command line I run:
browserify common.js > mycoolfile.js
I then include mycoolfile.js into my application and run it in the browser:
<script src="mycoolfile.js"></script>
The browserified file is included fine, but when I go to chrome dev tools console and type "horses" I get an undefined error. Any thoughts on what I may be doing wrong? Thank you
I think that you want to get at jquery via exports and you are also assuming that global lets you take a global a module creates and make an alias for it, but I don't think it does that. The above might work if jquery really did have a global called horses it creates, but it won't if you just make up that name arbitrarily. I think you are trying to do something more like this:
"browserify-shim": {
"jquery": {"exports": "jQuery"}
},

Resources