Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The dev server now checks if path matches a file #268

Merged
merged 3 commits into from
May 4, 2016

Conversation

KyleAMathews
Copy link
Contributor

Previously it'd return HTML if the accept header had text/html in it
which when a browser requests an unknown file, it always does.

This caused trouble when someone developing a site would try to click on
a link to a static file and instead of the dev server then returning
that file, it'd return an html file.

Fixes #255

Previously it'd return HTML if the accept header had text/html in it
which when a browser requests an unknown file, it always does.

This caused trouble when someone developing a site would try to click on
a link to a static file and instead of the dev server then returning
that file, it'd return an html file.

Fixes #255
@KyleAMathews
Copy link
Contributor Author

@benstepp I started down the path for testing this but ran into roadblock where needed to start dev server but... got stuck after trying for a while... if you want to take a crack at testing this that'd be appreciated. My test plan was 1) start dev server 2) request (using ava-http) a markdown file directly & its page equivalent and then assert that we got what was expected in each.

@benstepp
Copy link
Contributor

benstepp commented May 3, 2016

I should be able to take a real stab at this this weekend. I set this up and it works, but I'm not happy with the code duplication. Might be better and faster to test the Hapi server directly rather than booting up the CLI.

Some of the challenges with testing the development server

  • the asynchronous nature of ava and multiple processes wanting to bind to the same port. I just dunked a test.serial here, but there is most definitely a better solution.
  • how to tell when the server is actually ready to serve requests. Reading the stdout is probably not the answer either.
//support.js
export function develop (fixturePath) {
  const child = spawnNative(babel, ['--', gatsbyCli, 'develop'], { cwd: fixturePath })
  let stdout
  let stderr

  const ready = new Promise((resolve, reject) => {
    child.stderr.on('data', data => { stderr += data })
    child.stdout.on('data', data => {
      stdout += data
      if (includes(stdout, 'webpack building') &&
          includes(data.toString(), 'webpack built')) {
        resolve(true)
      }
    })

    child.on('error', error => reject({ error, stderr, stdout }))
    child.on('exit', code => {
      if (code === 0) {
        resolve({ code, stdout, stderr })
      } else {
        reject({ code, stdout, stderr })
      }
    })
  })

  return {
    start (t) {
      setTimeout(() => {
        t.end()
        child.kill()
      }, 10000)
      return ready
    },
    kill () {
      child.kill()
    },
  }
}
//in a test
test.serial('has a bundle', async t => {
  const server = develop(fixturePath)
  await server.start(t)
  const response = await http.getResponse('http://0.0.0.0:8000/bundle.js')
  t.is(response.statusCode, 200)
  server.kill()
})

@KyleAMathews
Copy link
Contributor Author

Oh this looks great!

Waiting for the Webpack "ok" text is a bit fragile but I can't think of any other way off-hand to know if it's working. And as long as Webpack doesn't change the text we're good.

On the port issue — something like this could work https://www.npmjs.com/package/find-open-port

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants