Cypress module resolution

[asirvadAbrahamVarghese]

Follow up work from this PR:
PR to add module resolution support in Cypress using @cypress/webpack-preprocessor because relative paths can be messier to handle going forward as mentioned here:
e.g.flashClassMap is something that we need across the test for expect_flash command. So, that can be imported using a module resolver alias that we define:
Instead of a relative import:
import { flashClassMap } from '../../../../support/assertions/assertion_constants';
we can do:
import { flashClassMap } from '@cypress-support/assertions/assertion_constants.js';
here @cypress-support is the alias that we define to get into cypress/support directory.

Why not set Cypress aliases directly in the webpack-config resolve.alias and use them in tests without relying on preprocessor?

Cypress, by default, uses its own internal preprocessor to bundle the test files. This preprocessor handles how the JavaScript and other assets are resolved and compiled before tests run in the browser. To apply a custom resolve.alias configuration to the tests, we need a mechanism to integrate that configuration with Cypress's preprocessor. This is precisely what @cypress/webpack-preprocessor facilitates. It allows to pass specific Webpack options (including resolve.alias) to Cypress's internal bundling process. Without the preprocessor, Cypress's default bundling mechanism would not be aware of custom aliases defined in webpack-config(our case shared.js) and would fail to resolve modules using those aliases, leading to errors like "Module not found."

Note:

We're using preprocessor version "2.0.1" at the moment. Once Webpack is upgraded, we should move to the latest version. Although it's compatible with Webpack 4+ and Babel 7+, we'll temporarily stay on an older version due to some errors. Also we're currently using a separate configuration object for Cypress instead of relying on the webpack config in shared.js, due to some existing errors. Hopefully, these issues will be resolved after upgrading to Webpack 5, at which point we can move the Cypress-specific aliases back into the main config.

@miq-bot add-label cypress
@miq-bot add-label enhancement
@miq-bot assign @jrafanie

[Fryguy]

LGTM - not sure on the name @cypress-support since it make it appear like those support files come from cypress as opposed to being built by us. Even so, that's very minor, so i'm good to merge this...if we come up with a better name, we can change in a follow up. Was thinking @cypress-miq-support, but maybe that's a bit wordy.

[jrafanie]

I think schedule form merge #9549 caused a conflict. I'll still take a look. Rebase when you can.

[jrafanie]

Honestly, I think I prefer adding the top-level cypress directory as '@cypress-dir' so the imports can be:

@cypress-dir/support/assertions/assertion_constants.js
@cypress-dir/support/assertions/expect_alerts.js

The other benefit is we can do other directories in @cypress-dir:

@cypress-dir/fixtures/empty_notifications.json

If we add factory bot commands to create objects you need for tests, they'll likely live in a directory that is a sibling to fixtures and support directories.

I guess we can add more directories to this list but I think a single toplevel cypress directory might enough.

[Fryguy]

So basically

Suggested change

	'@cypress-support': resolve(__dirname, 'cypress/support'),
	'@cypress-dir': resolve(__dirname, 'cypress'),

I'm surprised cypress doesn't have that built-in

[Fryguy]

I'm surprised cypress doesn't have that built-in

i.e. https://docs.cypress.io/app/references/configuration#Folders--Files - would be nice to do something like Cypress.config('cypressFolder') if something like that existed

closest I could find is supportFile under https://docs.cypress.io/app/references/configuration#e2e

[jrafanie]

yeah, I tried looking too... I don't get it. seeing ../../ with a different number of directories melts my brain 🫠 .

The idea came to me when looking at cypress-on-rails... I had to specify a different install_folder because it's in manageiq ui classic's cypress directory, not in the rails app, which is non-standard. https://github.com/search?q=repo%3Ashakacode%2Fcypress-playwright-on-rails%20install_folder&type=code

I'm doing this in my cypress-on-rails POC...

  CypressOnRails.configure do |c|
    c.install_folder = ManageIQ::UI::Classic::Engine.root.join("cypress/e2e")

Of course, this is in the ruby side but the need is the same: a convenient way to get the cypress directory to standardize how to "find" code relative to it.

[jrafanie]

LGTM - not sure on the name @cypress-support since it make it appear like those support files come from cypress as opposed to being built by us. Even so, that's very minor, so i'm good to merge this...if we come up with a better name, we can change in a follow up. Was thinking @cypress-miq-support, but maybe that's a bit wordy.

I agree, but offered a slightly different idea to use the top-level cypress directory as @cypress-dir as that will allow us to load fixtures, vcr cassettes, support files, custom commands, etc. specific to cypress.