Absolute include paths not working properly after 10.7.0 upgrade

[grivard]

I'm having a problem with my Cypress upgrade (9.6.0 to 10.7.0) and looking for some help or advice. After upgrading, absolute paths seem to be partially broken. I say partially because they work fine when my config file is at the project root, but I get errors when it's nested in a folder, where I need it to be (we have several config files for different test environments).

Our test configuration (from project root) was like this for 9.6.0:
cypress.config.json <-- see note* below
config*.json <-- .json config files
integration\various_hierarchies*.js <-- these are the spec files, which use absolute paths to include library files
support*.js <-- these are the said library files, which also use absolute paths to include other library files

*Normally, we don't have a cypress.config at project root. I moved one of the other files from config and renamed it cypress.config.json so that Cypress would modify it for me on upgrade. It did and the subset of tests I tried using that configuration ran as expected.

cypress.config.js <-- file created by Cypress from cypress.config.json, worked out of the box. Plugins were handled like this:
setupNodeEvents(on, config) { return require('./elsag/plugins')(on, config) },
I did experiment with setting up the plugins directly and bypassing plugins.index.js, but since we have multiple config files and this works, it seems like a better solution so I left it as is.

Except that I wanted it to be an absolute path, so I removed the leading . - which caused Cypress to fail with the following error:

I restored the relative path to cypress.config.js, copied the file to config/ and renamed it, and adjusted its relative path for the plugins location.

With that setup, my spec files work, including plugins. That is, unless they include a library using absolute paths (which most of them do of course) in which case I'll get this error:

It goes on to list other files that truly do not exist, but /elsag/support/audit-library.js most certainly does exist, assuming that / signifies project root.

The project root is 'C:\Workspace\Testing\Functional Testing' and 'C:\Workspace\Testing\Functional Testing\elsag\support\audit-library.js' does exist. And it will be found and will work, as long as I reference it using a relative path.

Note that in the error above, Cypress seems to be looking for the file in the integration folder, where it does not exist. 'C:\Workspace\Testing\Functional Testing\elsag\integration\elsag\support\audit-library.js' does not exist.

Spec files that include libraries using absolute paths work just fine, as long as my config file is at the root. It doesn't need to be named cypress.config.js, as long as it lives at project root.

Does anybody understand what's going on here? Thanks for taking the time to read this in any case.

[lmiller1990]

I tried this on linux and it's working fine:

$ cat /tmp/blah.js          
                                                                                                                                        
export default (on, config) => { 
  console.log('ok')
  return config 
}

$ cat cypress.config.ts       
                                                                                                                                      
import { defineConfig } from 'cypress'

export default defineConfig({
  fixturesFolder: false,
  e2e: {
    setupNodeEvents(on, config) {
      const blah = require('/tmp/blah.js')
      return blah.default // need to do this for es modules
    },
    baseUrl: 'http://localhost:8888',
  },
})

I wonder if it's windows specific? Or I am misunderstanding the instructions?

Another way you can make an absolute path (and be sure it's really absolute) is

setupNodeEvents (on, config) {
  const absPluginsPath = path.join(config.projectRoot, "cypress", "plugins")
}

config.projectRoot is the absolute path to your project.

I don't see any documentation on how Cypress handled absolute paths w.r.t pluginsFile in Cypress 9 - it looks like, from your post, in Cypress 9 / for a pluginsFile would be absolute, but Cypress 10 is interpreting it differently?

[grivard]

No problem. Hope you enjoyed your (I assume) vacation, and thanks for picking up the ball on this.

Something that might help would be an understanding of what's supposed to happen with absolute paths. Sounds like a silly question until we consider that absolute paths in this context are not really absolute.

Before Cypress 10, we could begin a path with a / anywhere and it would be "absolutely relative" to the project root. (I'm referring here to the use of import, include, and require within any .js file.)

As long as we store our config files at project root, that continues to work everywhere in Cypress 10 except in the config file itself when referencing plugins. No big deal, we just made it relative for now.

When we move our config files to a nested folder ({project root}/config/config-file.js), these 'absolutely relative from project root' paths no longer work.

In trying to find a simplest case, I discovered that I could reproduce this issue using "absolute" paths that are relative to project root. However, when I tried a path that was "absolute" relative to the drive, it worked. I tried that in our project, but it didn't work - possibly because the files referred to also had "absolute" references to project root. It's been a few weeks so I don't recall how far I took it, I just reached a point where I decided to stop chasing the squirrel.

If you can tell me what "absolute" paths are supposed to be relative to, I might have better luck getting you repro steps. All I can say now is that handling of absolute paths is inconsistent depending on the location of the config file, and it's possible there may be other factors since I recall some inconsistent results when I tried to narrow it down.

As far as case-sensitivity goes, yes it would seem that using toLowerCase would eliminate case-based discrepancies. A non-issue for us now (we have 2 live users and 2 shared VMs, so it was easy to work around).

Thanks again for your persistance!

[lmiller1990]

Something that might help would be an understanding of what's supposed to happen with absolute paths

I think the concept of an absolute path should really be what it is everywhere else in your operating system - absolute from the root. In linux-y OSes, it would be /, and on windows, it would be C:.

WDYT? If we can move forward with this simple definition, it will be easy to make everything consistent. If it means breaking changes, we will either need to do is quickly before v11 (going out soon) or it'll need to wait for v12.

[grivard]

WDYT? If we can move forward with this simple definition, it will be easy to make everything consistent. If it means breaking changes, we will either need to do is quickly before v11 (going out soon) or it'll need to wait for v12.

I agree with that meaning of an absolute path, of course (who could argue otherwise) but I would love it if you would support "absolute" paths as relative to product root, as worked in past versions. Maybe a config option? Or am I the only one who would ever use it?

If you decide to do that and can do it for v11, great! If you decide to do it for v12 and go with true absolute for v11, that will break things for us. Please let me know and we'll wait for v12.

If you decide not to do it but make everything consistent with true absolute, then when we upgrade we'll bite the bullet and update the paths in our files.

And then everything will just work... :)

[lmiller1990]

I don't think a config makes sense - better to add something new. It's hard to make a case for just a handful of uses cases, though. I wonder if we can write some code that'll just do something like

function absoluteFromProjectRoot (p: string) {
  return path.join(project_root, p)
}

You can probably infer the project root by traversing up until you hit a .git directory, or something.

[grivard]

I certainly agree, if I'm the only one using "absolute" references to project root it wouldn't make sense to implement something special for that. We can live with full absolute paths working consistently everywhere. Worst case our import/require/include spells out the full path, or maybe we can do something like const root = '/full/path/' along with import root + 'path/from/root/file.js'.

Again, I appreciate your attention to this. We have a workaround in place now (configs at project root) and will await a version where we can move them back into the config folder. Thanks!