-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
chore(build): swap in tsdx #212
Conversation
Great, thanks! What are the differences in output atm? |
I'm poking around at this, and I'm seeing some failing type tests that... shouldn't be. In particular, these for // typings:expect-error
const stringReducer: Reducer<string, PayloadAction<number>> = slice.reducer
// typings:expect-error
const anyActionReducer: Reducer<string, AnyAction> = slice.reducer @phryneas , any idea why these are failing? Not sure if it's due to a TS update, or the fact that we're using TS directly now. Also, I see that |
I think the biggest difference is you had externals for a few of the packages setup differently than how it's currently configured. I forget the specifics. I think there's also at least one rollup plugin I hadn't brought over yet.
Weird. Maybe a typescript bump error?
That should be pretty easy to fix, just need to crank that option down. |
Yeah, looking at the build output, the biggest immediate differences I see are:
I'm not as overly concerned about the UMD naming, especially since this is pre-1.0, but I do want our UMD files to be entirely self-contained (ie, I should be able to link the UMD file and write working Redux code right there). Also, could we rebase this against the |
I think both are those are pretty fixable. Just need to drop the externals plugin from the UMD build and tweak the output name. I can try both those later. |
Seems to be a bug introduced with TypeScript 3.6. State is inferred to PS: seems that TS3.6 infers the state type to extraReducers?: CaseReducers<State, any>
//to
extraReducers?: CaseReducers<NoInfer<State>, any> |
Bah, closed by the TS fix PR. Reopening. |
Welllll, something is definitely still not right here:
waitasec, that's the thing we just did in 0.8. um... okay, we've got a |
Deploy preview for redux-starter-kit-docs ready! Built with commit 0af1c4e https://deploy-preview-212--redux-starter-kit-docs.netlify.com |
Well, it builds now! I fixed the now-broken uses of So, now the question is what the output is like. I gotta head to bed, but will hopefully be able to look at it again tomorrow. |
- Removed "externals" so that all libs get bundled in - Fixed dev UMD output file name
Okay, fixed up the UMD externals and the dev filename. Output now looks basically equivalent to what we have already, minus a few Babel helpers and such. Also, interestingly, the CJS file appears to already be minified, which is surprising. I'm going to publish an alpha build and see if we can get some folks to test it out. |
Published Can folks try it out and see how it looks? |
You can look at the files in the package over at https://unpkg.com/browse/redux-starter-kit@0.9.0-alpha.0/ : I'm not really happy that we're shipping the src folder (I already know I'll be importing from there on accident), and in addition to that all those .d.ts files seperately instead of a rolled-up .d.ts (I already know that those will be problems with my @nickmccurdy can we do a rollup from that? This seems to be an open issue with jaredpalmer/tsdx#80 - that's why I personally prefer PS: yes, it already looks like that in older versions, but I'm already doing very weird imports from RSK as I recall. Will check back on those later on work. |
As this is a quite exotic case, I've created a reproduction repo here: https://github.com/phryneas/reproduction-non-rollup-types/blob/master/src/index.ts Given that by now, almost everything is re-exported from index.d.ts, I don't actually think this is too much of a problem any more (it was in the early days of RSK for me and I still have some workarounds for that in place!), but I'd love to see the types as one single file for 1.0. |
Oh, and one thing that is definitely a bug and needs to be adressed: |
@phryneas : y'know, I just realized that's why we only have a minified CJS file. It's because the custom Rollup config is overriding the output in both cases, by reading from one of the I'll fix things up this evening, including applying the DTS output, and publish another alpha. |
- Removed wrong filename causing CJS dev build to be overwritten - Change package `main` field to point to CJS index file
Been working on this this evening. Fixed the CJS filename, and was working on copying the changes @phryneas suggested. I just updated TSDX to 0.10.x on general principle... and it looks like it's now bundling all the typedefs into Based on that, I'm going to drop it from the setup for now. If someone wants to see what other options it offers down the road, I'm fine with that. |
This reverts commit 0be4ea9. Apparently IE11 doesn't support Object.assign(). Oops!
Oooo-kay, and that's completely dying in the tslint check with:
For every TS source file. What in the world? |
Whoa, this is bizarre. That actually showed up previously over in #198 . |
Prevents a whole bunch of repeats of this error: Definition for rule '@typescript-eslint/no-angle-bracket-type-assertion' was not found @typescript-eslint/no-angle-bracket-type-assertion
# Conflicts: # package-lock.json # package.json
Still don't know what's causing that weird lint error, but I was able to shut it up by explicitly disabling that lint rule. |
yayyyyyy and we're green! okay, I'm gonna go publish another alpha now. |
Okay, https://unpkg.com/browse/redux-starter-kit@0.9.0-alpha.1/dist/ |
Tried forking the last "Advanced Tutorial" sandbox and updating it to Any further comments or objections before I merge this in and publish 0.9.0? Or, should I just go ahead and jump to 1.0.0-rc.0? |
I'd publish it as 0.9 - that way we get some real-world feedback until you publish it as 1.0 |
Agreed. All right, I'll merge this in and put out 0.9. |
@markerikson Glad I could be of help! |
Yep, thanks! |
There's still work that needs to happen as when I last worked on this there were still some important differences in the output around externals, but I figured I'd issue this PR so one can see the differences in a rough state.
/cc @markerikson