I have multiple projects and I would like to implement cucumber-js E2E testing for all of them. I have a step definitions file which can be used for testing all of these projects, however I want to have multiple feature files with each project folder containing the feature files specific to the project. This is the layout:
step definitions:
projects/E2E/step_definitions/chat.js
feature files:
projects/project_1/features/feature_1.js
Right now, since the step definitions is outside of the features folder, I'm getting unimplemented steps error. Is there a way to specify the path to the step definitions when running cucumber-js?
I believe that the step definitions will be classed as a support file, which should mean you can include them like this:
npm run cucumberjs -- --require "../E2E/step_definitions/*.js"
Note
This assumes that your package.json is inside your project_1 directory and includes:
"scripts": {
"cucumberjs": "./node_modules/.bin/cucumber-js"
},
Reference
CucumberJS Official Documents for Requiring Support Files
Related
I use webpack 4 and electron-builder to bundle and build my Electron app. I noticed that native node modules inside the node_modules directory of the app.asar bundle still contain their C++ source files.
Is there a way to exclude certain file extensions from the build step?
electron-builder can exclude files in the files section of your package.json.
Default pattern / is not added to your custom if some of your patterns is not ignore (i.e. not starts with !). package.json and /node_modules// (only production dependencies will be copied) is added to your custom in any case. All default ignores are added in any case — you don’t need to repeat it if you configure own patterns.
Example
"!**/node_modules/*/{CHANGELOG.md,README.md,README,readme.md,readme}",
I'm playing around with Yarn 2, and I want to do something like this.
I have a monorepo of the structure:
/
packages/
shared-ts/
package.json
src/
lib*/
app-ts/
package.json
src/
lib*/
app-js/
package.json
src/
lib*/
where lib* denotes that the folder is gitignored, but is where the compiled code will live.
In this example, I have a dependency library shared-ts that is used by two apps, app-ts and app-js.
The conventional approach
The conventional approach to configuring a monorepo like this, is that in shared-ts I would have a package.json like:
"main": "lib/index.js"
"scripts" : {
"build": "tsc"
}
Where the build script will build index.js and index.d.ts into the lib folder.
When both app-ts and app-js then resolve the package, they look in the lib folder and find the index.js and in app-ts's case - the index.d.ts.
This works fine, except that the developers need to remember to run the build script if they have made changes to shared-ts in order for the changes to propagate across.
Where this could potentially become problematic is where there are many layers of dependencies.
Attempted work around 1 - point main to src/index.ts.
I can change shared-ts package.json to
"main": "src/index.ts"
"scripts" : {
"build": "tsc"
}
This generally won't work, a plain node process won't be able to parse the syntax in the .ts file (eg. the import keyword).
Potential workaround - publishConfig
So something I'm considering, but haven't tried yet is, using the publishConfig
fields in the package.json
This field contains various settings that are only taken into consideration when a package is generated from your local sources (either through yarn pack or one of the publish commands like yarn npm publish).
"main": "src/index.ts",
"publishConfig": {
"main": "lib/index.js"
}
The idea being that:
When you publish a package to npm, lib/index.js will be used as main. 👍 code is ready for consumption, no compilation required.
If being used directly in the monorepo src/index.ts will be used as main. 😕 This kind of works as if you were running app-ts with ts-node for example.
However, where this starts breaking down is:
Running app-js in a development environment (where you don't have any additional syntax parsing set up).
Practical current best solution
My current best solution is to 'just give up on this 'no compile' aspiration' - if a developer makes changes to some code, they need to re-run build for the changes to propagate across.
How about using this?:
import someValue from 'some-package/src/index';
I can do this in my monorepo like the image below
I believe using nx will be good choice here. While it won't help you run the uncompiled code, it has pretty good features. In particular, you can automatically run the affected:apps on certain changes. For example, if you have a start command, it will run the start command for all the affected apps.
I wanted the same thing but had to compromise on the "Automatic compilation on changes" option in my JetBrains IDE.
It allows me to debug with ts-node as well as run the code using the native node binary.
My Nestjs Project fails to start because it indexes other node projects out of its own project folder.
Seems like your configuration and thus your entity file does not recognize src/ as part of your application.
Try replacing src/directors/director.entity inside your movies.entity.ts with relative path such as ../../directors/director.entity and see what happens then.
I have a Monorepo under Lerna and Yarn Workspaces. The repo has packages which are published to npm and consumed outside the monorepo as well as within the monorepo. While developing in the monorepo we would like the main field of package.json for all such packages to point to the src directory, while when a package is used outside the monorepo, we would like the consumer to use the transpiled code in the dist folder.
I want this to be consistent across all uses of the packages, My current solution is to have the main field point to the dist folder. Then for each of the tools within the monorepo, namely jest, tsc, webpack, parcel I've had to come up with a different tool specific solution for aliasing the src directory instead of the dist directory. But I don't like the fact that I've had to do this work for each of these tools. It just doesn't seem scalable.
Has anybody come up with a lower level solution, where a module resolves to a different folder based on the environment?
Thank you.
If your internal code base is always transpiling the sources, why not just import { thing } from "my-package/src/main.js?
Then you can just leave the main field as dist for the consumers who ideally shouldn't have to keep track of additional paths when importing your packages.
There are a lot of details left our in your answer, but assuming you're using a single webpack/other instance to compile all your packages.
Another approach, since you're already coupled all your packages via the same compilation step, why not just use relative paths between the packages? That way you'll never have to act as a consumer but with slightly different needs.
And finally the third approach, which I think sounds a bit convoluted but should do exactly what you're asking for. Create a script that uses globby or some other npm package to grab all package.json files in your repository (excluding node_modules!). require() / iterate through these package.json manifest files and set the main field to an input value (say "dist"). Then, create two bin js files (hint: bin field) called set-main-dist and set-main-src, and possibly a third called unset-main.
Next, no matter what scripts you run in your package.json files at the root (or using lerna run), make sure to let the script look either like this:
"prebuild": "set-main-src"
or like this
"build": "set-main-src && build etc"
Hope one of these options work out for you. Remember that it's rarely worth going against the stream of usual patterns in tooling and what not. Make this one worth it.
I had exactly the same dilemma but with yarn3.
The solution importing always from source dint worked for my case, as the package itself might get published to npm too.
So after digging around I luckily found the package.json property publishConfig.main https://yarnpkg.com/configuration/manifest#publishConfig
With it I can change the main field from source to dist on npm publish.
Basically only for publishing we use a modified package.json.
Implemented in my package.json it looks like this:
{
"main": "./src/index.ts",
"publishConfig": {
"main": "./dist/index.js"
}
}
and when I run yarn npm publish or yarn pack the main field will be replaced temporary for the zip.
While all my tooling (jest and ts) can still rely on the main field pointing to the source.
I am trying to run a git bisect while using our automated tests to check the commit if it is the one causing the defect. The structure of our program is:
app
- cucumber_tests
- features/
- main_features/
- cucumber.yml
- src/
Obviously this is not the default/standard folder structure for running Cucumber tests as you would want the features folder to be at top-level of your app. This was not my choice and cannot be changed.
I can run the tests by cd into cucumber_test and then run. However, in order to run git bisect it must be done at same level as the .git folder.
My question is: is there a way to run the Cucumber tests from a parent directory of the features folder in Cucumber? Being able to read the cucumber.yml file would also be very beneficial.
Is there a way to tell Cucumber that you are not using the standard folder structure?
Edit: I have been able to get the tests started by using cucumber -r cucumber_tests/features cucumber_tests/features/main_features/first.feature. However, it is unable to find some of the step definitions part-way through the test.
It appears that cucumber is looking for files in app/features not app/cucumber_tests/features
You can still use the same folder structure. But you need to change the parameters in order to run your features. Otherwise this will not load step definitions. I hope you have step definitions inside the features folder. So now use this command to run the features: cucumber -r <absolute path of the features folder[C:\users\xyz\project\some_folder\features] absolute_path_feature_file[C:\users\xyz\project\some_folder\features\example.feature]
This way you cucumber will load your step definitions even if you have a different folder structure.