raise error if baseUrl is set and not supported

[davetron5000]

Addresses #25

I could not find a good place to write the documentation that baseUrl would be ignored by this library, and digging I figured instead an error could be shown if the baseUrl was not compatible.

This code is merely for discussion of this approach. I am not married to the way it's done as I did it as quickly as I could.

That said, I think a better change would be to modify https://github.com/testdouble/cypress-rails/blob/master/lib/cypress-rails/launches_cypress.rb to parse the baseUrl and use its parts.

The reason I didn't do that is that it's not clear to me if or how I should parse the cypress.json file. Should Config do this, or should LaunchesCypress do this or what?

So, thoughts on:

• Don't do that, and just merge a version of this to give an error for now. If so, please let me know if this implementation is good or how it could be better
• Yes, let's parse baseUrl. If so, thoughts on where is most appropriate to access cypress.json

[davetron5000]

Probably a lot more things to be checked here, but I figured I'd stop at path and scheme just to demonstrate the idea

[searls]

There are a few complicating factors to all this that apply to either approach, which is that there are multiple ways a user can change the base URL

• First, the environment variable which we're overriding

• Second, the JSON file as you've described

• Third, the configuration API

All of this suggests to me that what I'd probably rather do is avoid getting cute about interpreting how a user has configured cypress and instead expose a new configuration flag for cypress-rails that sets either the BASE_URL or, even easier, BASE_URL_PATH which we'd then tack on to our existing constructed-URL. This both saves on the complexity of this gem (wherein cypress is always going to be a moving target) and also gives users maximum control over the behavior that they want (at the expense of having to read the documentation if things don't work for them)

If you think this CYPRESS_RAILS_BASE_URL_PATH approach is reasonable, I'm happy to take a stab at implementing that

[davetron5000]

Yeah, I see what you mean. My other idea was to put a puts right before running cypress as that would've let me know what was happening (my problem was more confusion than having to set a path):

diff --git a/lib/cypress-rails/launches_cypress.rb b/lib/cypress-rails/launches_cypress.rb
index 83986c2..fcf2865 100644
--- a/lib/cypress-rails/launches_cypress.rb
+++ b/lib/cypress-rails/launches_cypress.rb
@@ -27,9 +27,9 @@ module CypressRails
 
       set_exit_hooks!(config)
 
-      system <<~EXEC
-        CYPRESS_BASE_URL=http://#{server.host}:#{server.port} "#{bin}" #{command} --project "#{config.dir}" #{config.cypress_cli_opts}
-      EXEC
+      command = "CYPRESS_BASE_URL=http://#{server.host}:#{server.port} \"#{bin}\" #{command} --project \"#{config.dir}\" #{config.cypress_cli_opts}"
+      puts "Launching Cypress with command '#{command}'"
+      system(command)
     end
 
     private

In aide of making a simple change, maybe that's the way to go? Happy to make that PR

[searls]

Ok, I added the aforementioned option and released it in 0.3.0 (relevant commit here: 214d545 )

Let me know how that works for you, but I'll close unless I hear back that it's not working for you (I only tested locally, forgive me)

(By the way, it occurred to me if you set Cypress.config('baseUrl', '/blah') in a support file instead of Cypress.json, you shouldn't need this option since it'll win over either cypress.json or the ENV flag)

[davetron5000]

Awesome, thanks!

[ariccio]

Heh, there's one more use case that this misses! I'm running against a react dev build, which I start in a harness that wraps cypress-rails. Or at least, I'm trying to get to wrap cypress-rails. I always am running against the same host (local), but usually have the backend on port 3000, and the dev build on 3001. CYPRESS_RAILS_BASE_PATH just appends. I'll open a separate issue or a PR of my own soon.