[release] 1.0.0 - Main thread

[whichsteveyp]

From another issue comment from @CMTegner, here's the general 'remaining tasks before v1' list.

@sprjr good to have you back! Here's my take on v1:

Blockers

#94
Nice-to-have (bugfixes, changes, improvements)

52

#68
#84
#92
#93
#103
#104
#106
There's a couple of topics we need to address either before v1 or soon thereafter:

Menu styling/positioning: The current implementation and default setup is not great. I'm tempted to just ditch it all and force the user to decide how to render the menu (we'll provide offset and other meta data). The alternative is to go for a relatively positioned menu, which we could easily do since we wrap both the input and the menu with a div. I could mock up both suggestions unless you have a better suggestion. Here are some issues for reference: #69, #70, #75, #100, #102
highlightedIndex: #52 and #106 try to fix some of the issues, but the fact is that highlightedIndex isn't updated when props.items changes. This needs to be fixed properly.
To be closed (already fixed, no longer applicable, etc)

13

15

30

45

50

53

64

74

95

97

99

105

• more, these were just the obvious ones

[whichsteveyp]

• Close existing non-applicable PRs
• Merge 94
• Determine list of additional PRs to mege in prior to release (from above list)
• Clean up Issues remaining as well
• "update reactcommunity.org" to prevent getting more bug reports for things we've already fixed.

[CMTegner]

@sprjr did you forget to push the updated build files after 1.0.0-rc4?

[CMTegner]

Let's add "update reactcommunity.org" to prevent getting more bug reports for things we've already fixed.

[whichsteveyp]

@CMTegner looks like I did, yea. Releasing rc5 now. Also I'll update the ticket here, but I've not heard of this site yet 😱

[whichsteveyp]

I merged several of the PRs in to master, and noticed that a test is failing - looking in to it a bit more but I'm not super familiar with the code as it's changed of the last few weeks. If I can get that test fixed up some time today/tomorrow I'll try to push a new RC out - that should be most of everything for v1?

[whichsteveyp]

@CMTegner I pin pointed the failing test issue to 3f83a92, it looks like the this.isInputFocused() function returns false for the test, but true in browser scenarios. I tried to think of a few ways around this but was tied up yesterday and probably most of this week. Think you could take a look? Since we don't track state internally, and props don't get updated due to the focus issue its not obvious to me what we can 'track' here for a successful test.

It otherwise works in browser, it appears - maybe it's not something we can test easily with the current framework.

[CMTegner]

@sprjr fixed in #115. The test was written while #65 was still pending, so it was expecting value to be in state. Good catch!

[CMTegner]

As for 1.0: I sat down to start work on the menu positioning issue yesterday, but got sidetracked by rackt-cli not working (#107). It's pretty much impossible to do development if you're on npm 3, unless you hack node_modules/rackt-cli. I'm assuming you're still on npm 2 since you can make rackt build and rackt release work.

I'm going to see if I can push something upstream to rackt-cli in my spare time this week, then get back to the menu issue.

Speaking of rackt release: It looks like most of the resources in build and dist are still at rc3. Perhaps we should remove build from git? We could also remove dist in favour of wzrd.in.

[whichsteveyp]

@CMTegner hmm, you know what - I'm probably out of habit assuming there was a prepublish script like I have on most of the other modules at work. That's no bueno, sorry.

That being said - yea I'm all for removing build/dist from git in favor of something that more efficiently publishes the files folks actually need. I went ahead and published rc6, which should include the correct build files on the version for folks.

I'll take a look at #115 and get that merged in - is #107 a blocker for the release or are we good after that? After that we can clear up whatever clutter we have + open a new 1.1.0 (or whatever semvers) thread make sense for the next major items, along with some patches along the way.

[CMTegner]

I don't think #107 is a blocker, as long as we manage to build and publish a working version using npm 2. It does however hinder new devs coming in to help us out, so I think it should be high on our list of things to fix. I haven't had much time this week to look at it, but hopefully I'll manage to set aside an hour this weekend.

[CMTegner]

Alright, cool! I've finally pushed a fix for rackt-cli (mzabriskie/rackt-cli#25). If it doesn't get merged in the next few days I'll update package.json to use my branch so there'll be less friction for collaborators. Should we get started on a 1.1 milestone?

[blackrabbit99]

@CMTegner @sprjr colleagues, I don't think that enormous dependencies from rackt-cli is good choice. karma, webpack etc are overhead for this tiny component IMHO.
So i propose make build system using browserify

"lint": "eslint **.js",
"build": "browserify entry.js",
"test": "jest",
"prepublish": "npm run build",    
"prebuild": "npm run test",
"pretest": "npm run lint"

Looks so easy and understandable for contributor. We won't have problems with updating webpack to v2 etc and no enormous dependencies.