Closed chucknelson closed 1 year ago
Thanks for the report. This sort of thing will help inform whether and when we can stop having a separate CommonJS module loading path. (My guess is that we won't ever be able to get rid of it. Dynamic import
is just too far from being a drop-in replacement for require
.)
Out of curiosity, why do you have an encoded slash in a directory name?
@sgravrock
Out of curiosity, why do you have an encoded slash in a directory name?
This is a result of how the build pipeline works at my current employer - the pipeline checks out branches into paths that represent the branch name and URL encodes characters like slashes. So for a branch feature/something
, the path it checks out files to is feature%2Fsomething
.
We found a similar issue with eslint - so it seems like what we're doing is good for finding edge cases, but maybe we'll just change it to convert slashes to hyphens or something haha.
Thanks for the info.
I think jsLoader: "require"
is the right solution, but we could probably produce a more helpful error message in this situation.
Versions
Issue
Jasmine 4 moving to dynamic import seems to break tests that run within a path that has an encoded slash.
Per https://jasmine.github.io/setup/nodejs.html#using-es-modules:
If I have a spec in the following path, it works fine:
my-project/src/my-test.spec.js
If the path has an encoded slash, though, it fails with the following error:
my%2Fproject/src/my-test.spec.js
This same error will happen if the spec is the only thing in an encoded path, like:
/my-project/src/some%2Ftests/my-test.spec.js
Workaround
Per the documentation referenced above, adding
"jsLoader": "require"
to the Jasmine config (e.g.,jasmine.json
) allows tests to work again, I assume because it falls back to how Jasmine 3 worked.