-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot find module ./cypress/commands/cypress/commands/ #191
Comments
I think I have a solution to the actual problem, there are several reasons why we are importing using that weird require syntax. The import is happening from the plugin's directory const customCommandObject = require(`../../../${projectName}${filePath}`); would do since the file path is from the main dir into the commands dir. I have noticed that my setup will not work with this plugin, at least as it is, since the project is a pnpm workspaces package. So that path is now so lost that reconciling it has been a headache. It comes out as a What I ended up doing was taking the bit of code that adds the commands to cy and do that from the e2e script instead. I removed all the plugin configs and inits. I wish this plugin could just have such an export so as to allow manual imports and addition of commands if the auto commands addition doesn't work, such as in my case. function isScopedMethod (methodName?: string) {
return !!methodName && methodName.endsWith('Scoped');
}
export function addModuleCommands (module) {
const methodNames = Object.keys(module);
methodNames.forEach((commandName: string) => {
const method = module[commandName];
if (isScopedMethod(commandName)) {
// @ts-ignore
Cypress.Commands.add(commandName, { prevSubject: 'element' }, method);
} else {
// @ts-ignore
Cypress.Commands.add(commandName, method);
}
});
} then I used in a import { addModuleCommands } from "cypress-codegen";
// then manually import the command files
import * as authCommands from "./auth.coms";
import * as cyGetter from './cy-getter.coms';
import * as delaysTimeouts from './delays-timeouts.coms';
/** add commands to cypress */
addModuleCommands(authCommands);
addModuleCommands(cyGetter);
addModuleCommands(delaysTimeouts); Which is then imported by I don't mind doing this, it's fine and much better than doing the original Cypress recipe of adding functions. How to solve the auto import? // This relative file path is extremely particular and for some unknown reason must be exactly this.
const customCommandObject = require(`../../../${projectName}cypress/commands/${filePath.replace(
commandsDirectory,
''
)}`); Well I have stated the reason, but solving this to work seamlessly in other environments requires a huge change from the way this is being done. |
@emahuni Thanks for pointing this out! I do realize this plugin does not currently work with pnpm because of the We can release a v2.0.0 that implements your |
@emahuni Check out version 2.0.0, which contains substantial improvements! |
New version 🎉 Sorry I spent time doing something and completely forgot to get back to this, by the time you asked me that question I had already changed a lot of things I intended to contribute back to this repo and left this unread, guess got too busy. I'll check out the new release, I hope you used the proposal it was okay to use the ideas. I'll share what I did in a new issue so we can improve on it. It even simplifies commands that expect a subject to not require a scope name. |
I love the new version. That's even better! |
I didn't see any scooped examples, are they still supported? |
We can maybe add support later, but for now I'd recommend adding those commands separately with the desired |
I am getting the following error:
I have traced the error from the following line in
src/plugin/index.ts
:to another line in
src/index.ts
:Notice that
sep
depends on operating system in node context, but somehow I think that is different with the globing that happens, because I am on Windows and running the whole thing in bash. I think there should be a mix-up of paths somewhere between bash and the OS. To resolve this, I suggest that the commands path be configurable when one configs the plugin itself to make it less opinionated and prone to breaking in different envs.For now doing the following should be fine.
This allows the replace statement used in
beforeAll
to replace the path regardless of the operating system's sep, hence the import statement can also be safely removed.The text was updated successfully, but these errors were encountered: