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

Add basic testing page for browser quicks #8589

Merged
merged 32 commits into from Jan 9, 2017

Conversation

@nhunzaker
Collaborator

nhunzaker commented Dec 16, 2016

Related to #8583


This is just the start. I'd like to dynamically pull in versions some how, and @gaearon mentioned renaming examples to fixtures, but it accomplishes most of what we need (I think).

Next step would be to create a basic template for a fixture.

test-page


@aweary Should we start working from a branch other than master? I can't do that, but I'd be happy to adjust the base of this PR to a browser-quirks (or whatever) branch on the main repo.

@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary Dec 16, 2016

Member

@aweary Should we start working from a branch other than master? I can't do that, but I'd be happy to adjust the base of this PR to a browser-quirks (or whatever) branch on the main repo.

I think I can just push changes to your branch, as long as you didn't uncheck that option when opening the PR.

Member

aweary commented Dec 16, 2016

@aweary Should we start working from a branch other than master? I can't do that, but I'd be happy to adjust the base of this PR to a browser-quirks (or whatever) branch on the main repo.

I think I can just push changes to your branch, as long as you didn't uncheck that option when opening the PR.

@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary Dec 16, 2016

Member

This is a good start 👍 How are we going to structure things at a high-level? Should tests be grouped by together in separate pages (input.html, textarea.html, select.html, etc.) or are we going to just keep it on a single page?

Personally, I think separate pages is the way to go since I expect this to get pretty large by the time we're done.

If we do use separate pages, does the iframe approach make sense? Would toggling between different pages work like toggling between different React versions?

Member

aweary commented Dec 16, 2016

This is a good start 👍 How are we going to structure things at a high-level? Should tests be grouped by together in separate pages (input.html, textarea.html, select.html, etc.) or are we going to just keep it on a single page?

Personally, I think separate pages is the way to go since I expect this to get pretty large by the time we're done.

If we do use separate pages, does the iframe approach make sense? Would toggling between different pages work like toggling between different React versions?

@nhunzaker

This comment has been minimized.

Show comment
Hide comment
@nhunzaker

nhunzaker Dec 16, 2016

Collaborator

I think I can just push changes to your branch, as long as you didn't uncheck that option when opening the PR.

Woah neat. Good deal.

I think we should do separate pages too. We could add a dropdown just like React versions. Maybe setup a script that generates it (or do it by hand for a while).

Another part of this is documentation. Where does documentation for fixes to random browser issues live?

Collaborator

nhunzaker commented Dec 16, 2016

I think I can just push changes to your branch, as long as you didn't uncheck that option when opening the PR.

Woah neat. Good deal.

I think we should do separate pages too. We could add a dropdown just like React versions. Maybe setup a script that generates it (or do it by hand for a while).

Another part of this is documentation. Where does documentation for fixes to random browser issues live?

@nhunzaker

This comment has been minimized.

Show comment
Hide comment
@nhunzaker

nhunzaker Dec 19, 2016

Collaborator

Updated the readme in examples/inputs to talk about the difference between defaultValue and value, and the concept of value detachment.

Collaborator

nhunzaker commented Dec 19, 2016

Updated the readme in examples/inputs to talk about the difference between defaultValue and value, and the concept of value detachment.

@nhunzaker

This comment has been minimized.

Show comment
Hide comment
@nhunzaker

nhunzaker Dec 19, 2016

Collaborator

@gaearon mentioned renaming examples to fixtures. For the sake of keeping this up to date with master, I'll go ahead and make a fixtures folder and move all of this work over to that. We can always rename/remove examples at a later point.

Collaborator

nhunzaker commented Dec 19, 2016

@gaearon mentioned renaming examples to fixtures. For the sake of keeping this up to date with master, I'll go ahead and make a fixtures folder and move all of this work over to that. We can always rename/remove examples at a later point.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Dec 22, 2016

Member

Excited to see work on this. Let me know if you get blocked on something!

Member

gaearon commented Dec 22, 2016

Excited to see work on this. Let me know if you get blocked on something!

@nhunzaker

This comment has been minimized.

Show comment
Hide comment
@nhunzaker

nhunzaker Dec 22, 2016

Collaborator

@gaearon you're fast! I was just writing this up..

Added:

  • Test for selects
  • Test for range inputs
  • Test for textareas

I also wrote up a section on form.reset(), documented the current issues with number inputs, and moved all of this work to a fixtures folder.

At this point, I feel good about everything. The only outstanding issues relates to fetching the version information in IE9 for the dropdown menu.

I think a next step would be to catalog past issues. I can think of three off the top of my head:

  1. Disabled buttons/inputs
  2. Assignment of min/max/step before value (causing display value issues in IE)
  3. Display value issues with improperly detached date inputs in iOS Safari /Android Chrome

Though I'm sure there are more.

Still, I think these are additive. At some point, I would love to check this in so that others can contribute to it more easily.

Collaborator

nhunzaker commented Dec 22, 2016

@gaearon you're fast! I was just writing this up..

Added:

  • Test for selects
  • Test for range inputs
  • Test for textareas

I also wrote up a section on form.reset(), documented the current issues with number inputs, and moved all of this work to a fixtures folder.

At this point, I feel good about everything. The only outstanding issues relates to fetching the version information in IE9 for the dropdown menu.

I think a next step would be to catalog past issues. I can think of three off the top of my head:

  1. Disabled buttons/inputs
  2. Assignment of min/max/step before value (causing display value issues in IE)
  3. Display value issues with improperly detached date inputs in iOS Safari /Android Chrome

Though I'm sure there are more.

Still, I think these are additive. At some point, I would love to check this in so that others can contribute to it more easily.

@nhunzaker

This comment has been minimized.

Show comment
Hide comment
@nhunzaker

nhunzaker Dec 22, 2016

Collaborator

And... just fixed the lint issues. Hopefully CI Passes now.

Collaborator

nhunzaker commented Dec 22, 2016

And... just fixed the lint issues. Hopefully CI Passes now.

@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary Dec 22, 2016

Member

@nhunzaker I added a small commit to show the values for the controlled <textarea/> and <select/>. I think we should make sure to always display the output for controlled components.

I think we need to decide on some high-level design structure before adding anything else. We want to have an accessible set of test cases that anyone can run through. It should be easy enough for a new contributor to intuitively follow. IMO the clearest way to do that is to have instructions inline.
Then we'd have a page with a set of generalized components (controlled, uncontrolled, etc.) and then below them a set of interactive test cases. That would look something like:

screen shot 2016-12-22 at 9 38 50 am

The advantages with this approach is that it makes it very, very easy for a contributor to open this page and work from a central place to test their changes. We could even have little checkboxes that people can use to track which tests they've done every time their refresh/check changes.

The downside is that our component structure increases in complexity. Each individual test case would likely need to maintain its own state and all that. If we did it this way, we'd likely want to start thinking about a better structure (instead of a bunch of inlined components)

Alternatively we could have them listed in each individual README. The advantage there is that its probably easier to maintain and easier to read over. The downside is that it makes it slightly harder to track what you're doing and requires you to have two pages open at once.

What do you think?

Member

aweary commented Dec 22, 2016

@nhunzaker I added a small commit to show the values for the controlled <textarea/> and <select/>. I think we should make sure to always display the output for controlled components.

I think we need to decide on some high-level design structure before adding anything else. We want to have an accessible set of test cases that anyone can run through. It should be easy enough for a new contributor to intuitively follow. IMO the clearest way to do that is to have instructions inline.
Then we'd have a page with a set of generalized components (controlled, uncontrolled, etc.) and then below them a set of interactive test cases. That would look something like:

screen shot 2016-12-22 at 9 38 50 am

The advantages with this approach is that it makes it very, very easy for a contributor to open this page and work from a central place to test their changes. We could even have little checkboxes that people can use to track which tests they've done every time their refresh/check changes.

The downside is that our component structure increases in complexity. Each individual test case would likely need to maintain its own state and all that. If we did it this way, we'd likely want to start thinking about a better structure (instead of a bunch of inlined components)

Alternatively we could have them listed in each individual README. The advantage there is that its probably easier to maintain and easier to read over. The downside is that it makes it slightly harder to track what you're doing and requires you to have two pages open at once.

What do you think?

@nhunzaker

This comment has been minimized.

Show comment
Hide comment
@nhunzaker

nhunzaker Dec 22, 2016

Collaborator

I like the first approach. Especially if we can make it available online. Each file would be a stand alone issue reproducer, making it easier to produce and avoids possibly missing context.

So let's start making cases?

Collaborator

nhunzaker commented Dec 22, 2016

I like the first approach. Especially if we can make it available online. Each file would be a stand alone issue reproducer, making it easier to produce and avoids possibly missing context.

So let's start making cases?

@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary Dec 22, 2016

Member

Should we move away from loading static HTML files and provide a server that users can run? It would make future deployment efforts easier. Then we could actually separate stuff out into different files and organize a bit better. And I think we'd sidestep CORS issue too since we can just request version history from the server.

Then users can just do npm run fixtures or something

Member

aweary commented Dec 22, 2016

Should we move away from loading static HTML files and provide a server that users can run? It would make future deployment efforts easier. Then we could actually separate stuff out into different files and organize a bit better. And I think we'd sidestep CORS issue too since we can just request version history from the server.

Then users can just do npm run fixtures or something

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Dec 22, 2016

Member

I feel like there's a lot of bikeshed potential if you move into the directions of servers and many pages. I would probably go with a single page and many components. Or you can use existing infra like Create React App.

Member

gaearon commented Dec 22, 2016

I feel like there's a lot of bikeshed potential if you move into the directions of servers and many pages. I would probably go with a single page and many components. Or you can use existing infra like Create React App.

@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary Dec 22, 2016

Member

I'm not saying do many individual pages, the current strategy of toggling between the different categories of components with a dropdown is a good approach. I'm just saying we can serve this file from localhost instead of just from file://. It would just be a simple webpack setup serving essentially the same thing we have now, except we wouldn't have to inline everything in a script tag or a single file.

Or you can use existing infra like Create React App.

I like that idea! That actually seems like the most logical way to do it.

Member

aweary commented Dec 22, 2016

I'm not saying do many individual pages, the current strategy of toggling between the different categories of components with a dropdown is a good approach. I'm just saying we can serve this file from localhost instead of just from file://. It would just be a simple webpack setup serving essentially the same thing we have now, except we wouldn't have to inline everything in a script tag or a single file.

Or you can use existing infra like Create React App.

I like that idea! That actually seems like the most logical way to do it.

@nhunzaker

This comment has been minimized.

Show comment
Hide comment
@nhunzaker

nhunzaker Dec 22, 2016

Collaborator

It would just be a simple webpack setup serving essentially the same thing we have now

Maybe we could even.... get incremental react builds!

Collaborator

nhunzaker commented Dec 22, 2016

It would just be a simple webpack setup serving essentially the same thing we have now

Maybe we could even.... get incremental react builds!

@nhunzaker

This comment has been minimized.

Show comment
Hide comment
@nhunzaker

nhunzaker Dec 22, 2016

Collaborator

I'm fine with either file:// vs http://, whatever is the easiest to author and set up for new contributors.

As for writing the tests themselves:

What I like about @aweary's decimal dropping example is that it includes specific reproduction steps for a confusing issue. Does it make sense to have a few pages for those strange edge cases, however maintain large pages by component type like we have now?

I can see a few focused examples from my past experience:

  1. The <input type=range /> issues hit in IE
  2. Disabled button bubbling
  3. Chrome/Safari backspace issues
  4. Chrome/Safari DateTime value detachment issues

So pages for a particular problem. Ones that require special handling inside of React, or we don't want to lose history on.

Does this make sense?

Collaborator

nhunzaker commented Dec 22, 2016

I'm fine with either file:// vs http://, whatever is the easiest to author and set up for new contributors.

As for writing the tests themselves:

What I like about @aweary's decimal dropping example is that it includes specific reproduction steps for a confusing issue. Does it make sense to have a few pages for those strange edge cases, however maintain large pages by component type like we have now?

I can see a few focused examples from my past experience:

  1. The <input type=range /> issues hit in IE
  2. Disabled button bubbling
  3. Chrome/Safari backspace issues
  4. Chrome/Safari DateTime value detachment issues

So pages for a particular problem. Ones that require special handling inside of React, or we don't want to lose history on.

Does this make sense?

@nhunzaker

This comment has been minimized.

Show comment
Hide comment
@nhunzaker

nhunzaker Dec 22, 2016

Collaborator

Also, I'm fine punting on specific test cases in favor of the "kitchen sink" style pages until we ship this. To me, they are more of documentation than anything else.

@aweary What does your availability look like? Would you like to own setting up a fixtures create-react-app? Otherwise I can probably get to it either tonight, or next Tuesday.

Collaborator

nhunzaker commented Dec 22, 2016

Also, I'm fine punting on specific test cases in favor of the "kitchen sink" style pages until we ship this. To me, they are more of documentation than anything else.

@aweary What does your availability look like? Would you like to own setting up a fixtures create-react-app? Otherwise I can probably get to it either tonight, or next Tuesday.

@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary Dec 22, 2016

Member

@nhunzaker I can own getting a fixtures app setup using create-react-app 🤘

Member

aweary commented Dec 22, 2016

@nhunzaker I can own getting a fixtures app setup using create-react-app 🤘

@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary Dec 22, 2016

Member

Does it make sense to have a few pages for those strange edge cases, however maintain large pages by component type like we have now?

I think we should have large pages for each category of components like now, and just have the general "kitchen sink" playground at the top, and then have a section below that lists each test case. That way if we provide a checkbox for each one they can just run through the list quickly and verify everything works with their changes, and it's easy to just scroll the page and see if there are any cases you didn't hit

Member

aweary commented Dec 22, 2016

Does it make sense to have a few pages for those strange edge cases, however maintain large pages by component type like we have now?

I think we should have large pages for each category of components like now, and just have the general "kitchen sink" playground at the top, and then have a section below that lists each test case. That way if we provide a checkbox for each one they can just run through the list quickly and verify everything works with their changes, and it's easy to just scroll the page and see if there are any cases you didn't hit

@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary Dec 27, 2016

Member

So I looked into getting an app setup using create-react-app and it's unfortunately not as straightforward as I'd hoped. Since we need to dynamically load different versions of React and ReactDOM, we need to make sure webpack doesn't bundle those. We can do that my marking them as external and making sure React and ReactDOM are available before the bundle is loaded, but that means we need to eject and I think that would defeat the purpose of using create-react-app in the first place (we now have our own infra to maintain anyways).

Member

aweary commented Dec 27, 2016

So I looked into getting an app setup using create-react-app and it's unfortunately not as straightforward as I'd hoped. Since we need to dynamically load different versions of React and ReactDOM, we need to make sure webpack doesn't bundle those. We can do that my marking them as external and making sure React and ReactDOM are available before the bundle is loaded, but that means we need to eject and I think that would defeat the purpose of using create-react-app in the first place (we now have our own infra to maintain anyways).

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Dec 27, 2016

Member

You can just read them from the global. CRA doesn't force you to import React in a specific way.

const ReactDOM = window.ReactDOM;
const React = window.React;
const Page = createPage(React, ReactDOM);
ReactDOM.render(<Page />, el);
Member

gaearon commented Dec 27, 2016

You can just read them from the global. CRA doesn't force you to import React in a specific way.

const ReactDOM = window.ReactDOM;
const React = window.React;
const Page = createPage(React, ReactDOM);
ReactDOM.render(<Page />, el);
@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary Dec 27, 2016

Member

I somehow didn't even think of doing that, thanks!

Member

aweary commented Dec 27, 2016

I somehow didn't even think of doing that, thanks!

@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary Jan 3, 2017

Member

@nhunzaker @gaearon I've pushed my commit with the application created using create-react-app (99bfa28) . It works pretty well overall. There are some notes in the commits about implementation details, and I'm not 100% on the folder structure, but I wanted to get something up for review 👍

Member

aweary commented Jan 3, 2017

@nhunzaker @gaearon I've pushed my commit with the application created using create-react-app (99bfa28) . It works pretty well overall. There are some notes in the commits about implementation details, and I'm not 100% on the folder structure, but I wanted to get something up for review 👍

Show outdated Hide outdated fixtures/README.md
@nhunzaker

This comment has been minimized.

Show comment
Hide comment
@nhunzaker

nhunzaker Jan 6, 2017

Collaborator

Done. I've also updated the readme with setup instructions.

Collaborator

nhunzaker commented Jan 6, 2017

Done. I've also updated the readme with setup instructions.

@nhunzaker

This comment has been minimized.

Show comment
Hide comment
@nhunzaker

nhunzaker Jan 6, 2017

Collaborator

As for inlining the test case descriptions. Every description other than text inputs was pretty low value. Just a quick line that said something like "This fixture tests <textarea />".

However the input README is pretty involved, and talks through some important concepts.

@gaearon did you envision that we would put that information within the test case? Or rather that we'd place instructions for how to use the test fixture along side the test case? Where should we put something like fixtures/inputs/README.md

Collaborator

nhunzaker commented Jan 6, 2017

As for inlining the test case descriptions. Every description other than text inputs was pretty low value. Just a quick line that said something like "This fixture tests <textarea />".

However the input README is pretty involved, and talks through some important concepts.

@gaearon did you envision that we would put that information within the test case? Or rather that we'd place instructions for how to use the test fixture along side the test case? Where should we put something like fixtures/inputs/README.md

@@ -19,6 +19,8 @@ docs/downloads/*.zip
docs/vendor/bundle
examples/shared/*.js
examples/**/bundle.js
fixtures/dom/public/react-dom.js
fixtures/dom/public/react.js
test/the-files-to-test.generated.js
*.log*
chrome-user-data

This comment has been minimized.

@nhunzaker

nhunzaker Jan 6, 2017

Collaborator

Thanks, 👍

@nhunzaker

nhunzaker Jan 6, 2017

Collaborator

Thanks, 👍

@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary Jan 6, 2017

Member

@nhunzaker I think we could have the READMEs explain high-level concepts and implementation details that are good to know, but not crucial for testing. Then we inline instructions that are just to-the-point directions on how to validate expected behavior. That way we don't include too much detail on the fixtures page, but its still available somewhere.

Member

aweary commented Jan 6, 2017

@nhunzaker I think we could have the READMEs explain high-level concepts and implementation details that are good to know, but not crucial for testing. Then we inline instructions that are just to-the-point directions on how to validate expected behavior. That way we don't include too much detail on the fixtures page, but its still available somewhere.

@nhunzaker

This comment has been minimized.

Show comment
Hide comment
@nhunzaker

nhunzaker Jan 6, 2017

Collaborator

@aweary that would be my preference as well.

Collaborator

nhunzaker commented Jan 6, 2017

@aweary that would be my preference as well.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jan 6, 2017

Member

Sounds good. Really, the only thing necessary is that it's easy both for the team and the casual contributors to understand what they should test and how it should behave.

Member

gaearon commented Jan 6, 2017

Sounds good. Really, the only thing necessary is that it's easy both for the team and the casual contributors to understand what they should test and how it should behave.

@jquense

This comment has been minimized.

Show comment
Hide comment
@jquense

jquense Jan 9, 2017

Collaborator

👋 just finding this PR. I'd be happy to help out if there is still work to be done :)

Collaborator

jquense commented Jan 9, 2017

👋 just finding this PR. I'd be happy to help out if there is still work to be done :)

There are a couple of important concepts to be aware of when working on text
inputs in React.
## `defaultValue` vs `value`

This comment has been minimized.

@jquense

jquense Jan 9, 2017

Collaborator

perhaps worth noting that React explicitly supports changing the value of an input imperatively via JavaScript. This isn't an obvious invariant when making changing to input code, but required to properly support autofilling, password managers, and general DOM interop (unfortunately).

@jquense

jquense Jan 9, 2017

Collaborator

perhaps worth noting that React explicitly supports changing the value of an input imperatively via JavaScript. This isn't an obvious invariant when making changing to input code, but required to properly support autofilling, password managers, and general DOM interop (unfortunately).

This comment has been minimized.

@gaearon

gaearon Jan 9, 2017

Member

Good catch. We’ll want to add a fixture for this.

@gaearon

gaearon Jan 9, 2017

Member

Good catch. We’ll want to add a fixture for this.

// https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input
let types = [
'text', 'email', 'number', 'url', 'tel',
'color', 'date', 'datetime-local',

This comment has been minimized.

@jquense

jquense Jan 9, 2017

Collaborator

AFAIK datetime-local is still supported as datetime in some browsers, I'm not sure if that's worth adding or noting tho.

@jquense

jquense Jan 9, 2017

Collaborator

AFAIK datetime-local is still supported as datetime in some browsers, I'm not sure if that's worth adding or noting tho.

@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary Jan 9, 2017

Member

👋 just finding this PR. I'd be happy to help out if there is still work to be done :)

👋 @jquense we still need to write fixtures for all the specific test cases. Right now we just have the "kitchen sink" pages with controlled/uncontrolled variants of a few input types.

I mentioned in #8589 (comment) that we might want to write a component that makes it easy to create new fixtures that can be marked as completed (for users validating behavior when making changes)

Any input (heh) you have on scenarios we should be explicitly testing would be amazing! I'll start getting a list together soon and add it to the top comment in this PR.

Member

aweary commented Jan 9, 2017

👋 just finding this PR. I'd be happy to help out if there is still work to be done :)

👋 @jquense we still need to write fixtures for all the specific test cases. Right now we just have the "kitchen sink" pages with controlled/uncontrolled variants of a few input types.

I mentioned in #8589 (comment) that we might want to write a component that makes it easy to create new fixtures that can be marked as completed (for users validating behavior when making changes)

Any input (heh) you have on scenarios we should be explicitly testing would be amazing! I'll start getting a list together soon and add it to the top comment in this PR.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jan 9, 2017

Member

Done. I've also updated the readme with setup instructions.

Actually I think fixtures/build disappeared. This name is probably in gitignore.
You can name it fixtures/packaging instead.

Member

gaearon commented Jan 9, 2017

Done. I've also updated the readme with setup instructions.

Actually I think fixtures/build disappeared. This name is probably in gitignore.
You can name it fixtures/packaging instead.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jan 9, 2017

Member

After fixing #8589 (comment) feel free to merge this when you feel like it.
The PR is getting quite large.

Member

gaearon commented Jan 9, 2017

After fixing #8589 (comment) feel free to merge this when you feel like it.
The PR is getting quite large.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jan 9, 2017

Member

In addition to fixing #8589 (comment) you'll also need to fix the build fixtures to resolve paths correctly since their relative paths to the build folder are now wrong. You can try to go through the README to see the problem.

Member

gaearon commented Jan 9, 2017

In addition to fixing #8589 (comment) you'll also need to fix the build fixtures to resolve paths correctly since their relative paths to the build folder are now wrong. You can try to go through the README to see the problem.

@nhunzaker

This comment has been minimized.

Show comment
Hide comment
@nhunzaker

nhunzaker Jan 9, 2017

Collaborator

@gaearon: Sorry for going quiet. Busy day! I should be able to get to this feedback tonight.

Collaborator

nhunzaker commented Jan 9, 2017

@gaearon: Sorry for going quiet. Busy day! I should be able to get to this feedback tonight.

@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary Jan 9, 2017

Member

@nhunzaker I'm working on it right now, I'll get it fixed and then merged 😃

Member

aweary commented Jan 9, 2017

@nhunzaker I'm working on it right now, I'll get it fixed and then merged 😃

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jan 9, 2017

Member

Thanks @aweary!

Member

gaearon commented Jan 9, 2017

Thanks @aweary!

@nhunzaker

This comment has been minimized.

Show comment
Hide comment
@nhunzaker

nhunzaker Jan 9, 2017

Collaborator

@aweary True friend ❤️

Collaborator

nhunzaker commented Jan 9, 2017

@aweary True friend ❤️

module.exports = {
entry: './input',
output: {
filename: 'output.js',
},
resolve: {
root: '../../build/packages',
root: path.resolve('../../../build/packages/'),

This comment has been minimized.

@aweary

aweary Jan 9, 2017

Member

@gaearon looks like webpack requires resolve.root to be absolute, had to make this change for the webpack packaging fixtures to build

@aweary

aweary Jan 9, 2017

Member

@gaearon looks like webpack requires resolve.root to be absolute, had to make this change for the webpack packaging fixtures to build

This comment has been minimized.

@gaearon

gaearon Jan 9, 2017

Member

Got it, thanks

@gaearon

gaearon Jan 9, 2017

Member

Got it, thanks

@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary Jan 9, 2017

Member

Made the required changes, just waiting on CI to approve and will merge after 👍

Member

aweary commented Jan 9, 2017

Made the required changes, just waiting on CI to approve and will merge after 👍

@aweary

aweary approved these changes Jan 9, 2017

@aweary aweary merged commit a1dd107 into facebook:master Jan 9, 2017

1 check passed

ci/circleci Your tests passed on CircleCI!
Details

@aweary aweary referenced this pull request Jan 9, 2017

Closed

[RFC] Testing Browser Compatibility #8583

3 of 12 tasks complete
@acdlite

This comment has been minimized.

Show comment
Hide comment
@acdlite

acdlite Jan 10, 2017

Member

Please rebase/squash commits like this before merging them. It creates noise in the commit history.

Member

acdlite commented on 5e53c0c Jan 10, 2017

Please rebase/squash commits like this before merging them. It creates noise in the commit history.

This comment has been minimized.

Show comment
Hide comment
@nhunzaker

nhunzaker Jan 10, 2017

Collaborator

Sorry :(

Collaborator

nhunzaker replied Jan 10, 2017

Sorry :(

This comment has been minimized.

Show comment
Hide comment
@acdlite

acdlite Jan 10, 2017

Member

No problem 👍

Member

acdlite replied Jan 10, 2017

No problem 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment