Fixed a bundling issue that prevented the keys() export to be preserved in the previous release
#3118
Conversation
…rved in the previous release
🦋 Changeset detectedLatest commit: 8aa614b The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 8aa614b:
|
CodeSee Review Map:Review in an interactive map View more CodeSee Maps Legend |
| export default [ | ||
| createNpmConfig({ | ||
| input: 'src/index.ts', | ||
| input: npmInputs, |
There was a problem hiding this comment.
Even though we were using preserveModules here the whole thing was still subject to tree-shaking and since keys was not really used by anything... it got removed by Rollup. By providing an array of inputs we let Rollup to know that we expect stuff to be importable directly from those entries so it has to preserve every public export of every input - and that makes keys to be preserved
| @@ -48,9 +49,11 @@ const createUmdConfig = ({ input, output, target = undefined }) => ({ | |||
| ] | |||
| }); | |||
|
|
|||
| const npmInputs = glob.sync('src/!(scxml|invoke|model.types|typegenTypes).ts'); | |||
There was a problem hiding this comment.
those were mainly type-only files and Rollup has been complaining about empty entries so I've filtered them out. The whole thing should still work correctly - and those files are still accessible at the type-level because .d.ts files are still produced for them
fixes #3115