-
-
Notifications
You must be signed in to change notification settings - Fork 227
Conversation
645ccaf
to
67f522c
Compare
67f522c
to
1be2848
Compare
package.json
Outdated
"build:cjs-min": | ||
"MINIFY=true rollup -c --output.format cjs --output.name 'react-popper' --output.file dist/react-popper.min.js", | ||
"demo": "parcel --out-dir demo/dist demo/index.html", | ||
"prepare": "npm run build", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct me if I am wrong, but perpare
will run when users install this library as a dependency (as well as before the package is published). Did you intend to have it build every time it is installed?
prepublishOnly
would run the build only prior to publishing (not on install).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
npm sucks, there's not a real solution to this...
If you use prepare
, it will run on both the cases you mentioned, but if you use prepublishOnly
it's not going to wait for it to finish before publishing, at least that was the case the last time I checked the discussion on the npm repo.
This is the gist of the discussion:
but you can't (currently) put code into prepublishOnly that allows you to run a build step before publishing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree,
Since
[email protected]
, the npm CLI has run theprepublish
script for bothnpm publish
andnpm install
, because it's a convenient way to prepare a package for use. It has also turned out to be, in practice, very confusing. As of[email protected]
, a new event has been introduced,prepare
, that preserves this existing behavior. A new event,prepublishOnly
has been added as a transitional strategy to allow users to avoid the confusing behavior of existing npm versions and only run onnpm publish
(for instance, running the tests one last time to ensure they're in good shape).
1be2848
to
e2a672b
Compare
src/index.js
Outdated
export { default as Manager } from './Manager'; | ||
export { default as Target } from './Target'; | ||
export { default as Popper } from './Popper'; | ||
export { default as Arrow } from './Arrow'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hope this will not cause the same problem that #93 solved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the compiled code everything looks good, anyway the old syntax is not valid at all with Rollup so there's not much choice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#93 was fixing a bug with the babel output not the webpack build.
You could compare the file lib/react-popper.js
to old ones to be sure:
[email protected] <-- Seems good for everyone
[email protected] <-- Wrong ESM
[email protected] <-- Wrong This was when I used the same syntax as you here.
[email protected] <-- Seems good for everyone
@Justkant @TheSharpieOne did anyone of you have a chance to test this? I ran it on some internal code and it seems to work fine, but I'd like you to double check if possible |
Hi, I had no time to test it so far. |
I just tried it with reactstrap as that's what was giving me issues before. It is not working and is acting similar to 0.8.2
I can use the link in the error to determine that I can add additional configurations to my rollup config (telling it about react-popper's exports), but I don't think that should be needed. 0.9.0: https://unpkg.com/[email protected]/lib/react-popper.js is the same as |
Umh |
.babelrc
Outdated
"transform-export-extensions" | ||
] | ||
"presets": [["env", { "modules": false }], "stage-2", "react"], | ||
"plugins": ["transform-class-properties"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here you don't need to use the stage-2
Don't you still need transform-object-rest-spread
?
Also I used transform-export-extensions
without { "modules": false }
to be able to transform export Manager from './Manager'
correctly. But it's a problem with rollup if you want to use his native support of esm.
We could use babel env feature to use rollup native modules & let babel transform for the lib build
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@FezVrasta
Do we need everything in stage-2 & stage-3 ?
I think we only need transform-class-properties
and transform-object-rest-spread
, the babel-preset-env
takes care of the rest.
Anyway it's ok to use stage-2 but transform-class-properties
becomes redundant here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kept stage-2
and removed the plugin
The part that I don't understand is why there's a problem with this version [email protected] |
@FezVrasta do you really think that Also tried |
the |
You're right, I didn't see the |
@FezVrasta don't forget to copy the TS definitions file into dist when bundling (or when releasing) as it's missing right now in the npm dist for next tag (but still referenced from 'package.json'). |
@rolandjitsu is my last commit okay? |
FWIW, I think the Reasoning: TL;DR: making lib be cjs rather than esm and putting a single esm file in dist provides the ability to import single components in both cjs and esm (the latter via tree-shaking) and more efficient full bundles for both cjs and esm. |
|
Please give a spin to |
0.9.1-alpha.1 works both for building other libraries with rollup (such as reactstrap itself) and when consuming it in an end project with webpack (such as when using reactstrap in your project). Those are pretty much my tests to ensure it doesn't break reactstrap. I just wanted to note this (food for thought): |
@FezVrasta it's perfect. |
27641dd
to
31aafea
Compare
@TheSharpieOne you're right about the file size, but atm we are shipping the whole popper.js library so I think it's still an improvement :-) If we can come with a solution to this last size problem we can fix it later. |
@FezVrasta Just to confirm it looks like the unminified filesize went from 103KB (0.8.3) to 15KB (0.9.1) with similar savings on the minified side (29.4KB -> 7.4KB) !?!?! This is amazing! |
Yes that's right. Previously react-popper bundled its own version of Popper.js, now it references it as external dependency. I'm also working on a React 16 rewrite that should reduce even more the final size and simplify code and API. |
Gotcha. Not a problem so at least the prop-types stuff got included (that should help a little in the production builds). With 0.9.1+ will end users now need to include both |
The advantage is that if you already use |
Awesome, gotcha. |
Nice to see all those improvements, nice work @FezVrasta ✌️ |
It's going to be render props powered, context managed by the new context API, and not much else actually. The API will be much leaner and the internal logic will get simplified. |
Are you going to target 16.3.0 as the min version of react for the new context API? |
I'm not sure what version I do specifically need, I think I just need fragments support actually? But probably it could even work on React 15 if one doesn't use the renderProps in some weird manner. The API looks like this so far: <Manager>
<Target>{getTargetRef =>
<button ref={getTargetRef}>target</button>
}</Target>
<Popper>{({ getPopperRef, style }) =>
<div ref={getPopperRef} style={style}>
popper
<Arrow>{({ getArrowRef, style }) =>
<div ref={getArrowRef} style={style} />
}</Arrow>
</div>
}</Popper>
</Manager> |
fixes #106, fixes #80, fixes #82
This PR:
babel-plugin-transform-react-remove-prop-types
to allow to strip PropTypes.Todo:
I'd love to have some feedbacks and have few people test the new output to make sure it still works as expected.
You are able to test this branch using
react-popper@next