Support esm via package.json routes #455
Conversation
| @@ -2,14 +2,18 @@ | |||
| "name": "react-transition-group", | |||
| "version": "2.5.3", | |||
| "description": "A react component toolset for managing animations", | |||
| "main": "lib/index.js", | |||
| "main": "lib/cjs/index.js", | |||
There was a problem hiding this comment.
wouldnt it make sense to also remove semantic-release-alt-publish-dir ? and restructure the rest to more common structure? i find this indirection rly confusing when i track what particular scripts do
There was a problem hiding this comment.
I hear that, tho I'm inclined to accept some more confusing build output if it means easier, and shorter imports when consuming. I mean we are already doing this package json thing which is a very uncommon pattern right?
There was a problem hiding this comment.
right, although I wasnt proposing making the imports longer but rather building to dist (and some files to root) and just using files/npmignore to filter out what gets published - this wouldnt change how the lib is consumed, only how it gets built
There was a problem hiding this comment.
it would effect how they are consumed tho wouldn't It? you can't use files and npmignore to avoid import 'foo/lib/module' you need to to publish everything without a lib, e.g. you can't tell a package to resolve 'foo/module' to 'foo/lib/module'
There was a problem hiding this comment.
i'd like the build step to not produce a ton of root directories/files they should be scoped under /build or whatever, otherwise it gets confusing and harder to understand whats happening in the repo, and gitignores need to keep being updated for new files etc. The publishDir thing doesn't bother me b/c it only produces an inconsistency between whats in npm and the repo structure, that, i think is fine. There isn't any need for the two to match.
There was a problem hiding this comment.
you can with if you make foo/module a directory with package.json in it which would have main field pointing to foo/lib/module (which this PR already adds with cherry-pick tool)
my proposal is merely to change where npm artifacts gets outputted to, because I feel that this alt-publish-dir introduces a confusing indirection
|
Is this good to merge? |
|
@TrySound I'll test this in the next few days and apply fixes if necessary, taking into account the conversation in this PR. |
# [2.7.0](v2.6.1...v2.7.0) (2019-03-22) ### Features * support ESM (tree-shaking) ([#455](#455)) ([ef3e357](ef3e357))
|
🎉 This issue has been resolved in version 2.7.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
I tested tree-shaking and it works! I resolved some conflicts and pushed the changes in a separate commit. Thanks! |
|
@TrySound Do you want to pull the PR back up and just mark it appropriately as breaking this time around? It's really only weird interop stuff that's breaking; the CJS exports per se are still fine. |
# [2.7.0](reactjs/react-transition-group@v2.6.1...v2.7.0) (2019-03-22) ### Features * support ESM (tree-shaking) ([#455](reactjs/react-transition-group#455)) ([ef3e357](reactjs/react-transition-group@ef3e357))
# [2.7.0](reactjs/react-transition-group@v2.6.1...v2.7.0) (2019-03-22) ### Features * support ESM (tree-shaking) ([#455](reactjs/react-transition-group#455)) ([ef3e357](reactjs/react-transition-group@ef3e357))
# [2.7.0](reactjs/react-transition-group@v2.6.1...v2.7.0) (2019-03-22) ### Features * support ESM (tree-shaking) ([#455](reactjs/react-transition-group#455)) ([ef3e357](reactjs/react-transition-group@ef3e357))
# [2.7.0](reactjs/react-transition-group@v2.6.1...v2.7.0) (2019-03-22) ### Features * support ESM (tree-shaking) ([#455](reactjs/react-transition-group#455)) ([ef3e357](reactjs/react-transition-group@ef3e357))
Ref #77