Hi,
This only happens if the = is the last character of the variable. Could be very annoying with base64 environment variables.
Bug 馃悳
For a variable named FOO with a value of BAR=:
./node_modules/.bin/cypress run ${PATH} --env FOO=BAR=
./node_modules/.bin/cypress run ${PATH} --env FOO='BAR='
./node_modules/.bin/cypress run ${PATH} --env FOO="BAR=",
./node_modules/.bin/cypress run ${PATH} --env CY=PRESS,FOO=BAR=
Cypress.config('FOO') would return BAR and not BAR=, with all 4 ways. Using such variable in cypress.json or cypress.env.json doesn鈥檛 strip the =.
The = isn鈥檛 stripped.
This seems like a very limited edge case: having values of variables that include = characters. Is there a Node lib that can successfully parse and split values by = if some of the strings include =?
While this is an edge case, this is still quite a bug and it does not seem too hard to fix. I don鈥檛 know your code base, but something as simple as the following should do the trick (no matter the language):
const value = 'CY=PRESS,FOO=BAR='
const pairs = value.split(/\s*,\s*/)
pairs.forEach(pair => {
const index = pair.indexOf('=')
const key = pair.slice(0, index)
const value = pair.slice(index + 1)
console.log({ key, value })
})
Output:
{ key: "CY", value: "PRESS" }
{ key: "FOO", value: "BAR=" }
Am I missing something maybe?
I am thinking here you could just use the module API and not use it from the command line.
The module API accepts env as an object literal where you could specify this correctly.
Unfortunately, that is not really an option for us. We do rely on cypress.json though but still, the bug remains. :)
Another option is to use a different character other than = and then in your Cypress supportFile just iterate through them all and replace the special character with =.
That should also work.
// cypress/support/index.js
const obj = Cypress.env()
// loop
// replace special char with `=`
That seems like a super hacky solution for something that should inherently be fixed. We pass a base64 encoded string through --env which contains an equal. This value comes from a different service. I鈥檓 not sure replacing = with another character only to restore equals slightly further down the pipe is a good thing.
Don鈥檛 get me wrong, I really appreciate you providing workarounds for us! As I said, right now we rely on cypress.json which is fine-ish. But is there any reason this problem would be hard to fix for you?
We use https://github.com/substack/minimist to parse the args. If it doesn't support this out of the box then we'd have to add our own sanitation layer.
To parse the arguments from the command line, yes. But once you have the value of the --env argument, I believe you parse it yourself, right? I don鈥檛 think minimist provides a way to decompose arguments value on arbitrary syntax. Or am I missing something?
We will look at it. Worst case you'll have to wait until we open source and then just submit a PR. We are open sourcing at our next major release 1.0.0 which is happening soooooooon.
Happy to try contributing when the code is open source. :)
Fixed in 1.0.2.
Most helpful comment
We will look at it. Worst case you'll have to wait until we open source and then just submit a PR. We are open sourcing at our next major release
1.0.0which is happening soooooooon.