Skip to content
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

Bundle all entry points with rollup #8

Merged
merged 2 commits into from
Jun 3, 2019
Merged

Bundle all entry points with rollup #8

merged 2 commits into from
Jun 3, 2019

Conversation

TrySound
Copy link
Contributor

@TrySound TrySound commented Jun 2, 2019

Here's a set of result files

  • ./dist/cjs/i18nextChainedBackend.js
  • ./dist/esm/i18nextChainedBackend.js
  • ./dist/umd/i18nextChainedBackend.js
  • ./dist/umd/i18nextChainedBackend.min.js

Amd and iife are part of umd format.

Babel helpers are reused across packages.

Windows specific scripts are simplified.

If you agree I can make PRs in another packages.

Also jsnext:main was deprecated a few years ago. It's better to remove in in the next major release.

Here's a set of result files
- ./dist/cjs/i18nextChainedBackend.js
- ./dist/esm/i18nextChainedBackend.js
- ./dist/umd/i18nextChainedBackend.js
- ./dist/umd/i18nextChainedBackend.min.js

Amd and iife are part of umd format.

Babel helpers are reused across packages.

Windows specific scripts are simplified.
@jamuhl
Copy link
Member

jamuhl commented Jun 3, 2019

@TrySound looks great for me...to make sure I get no "complains" I will make a major version with those changes - as whoever imported something like import * as utils from './dist/commonjs/utils'; would be not amused (won't be a lot...but better be save). -> so jsnext:main could be removed on the same run...

@jamuhl jamuhl merged commit be3ad83 into i18next:master Jun 3, 2019
@TrySound
Copy link
Contributor Author

TrySound commented Jun 3, 2019

Why don't you use lock files? They speed up installing a lot and improve safety (at least yarn does).

@TrySound TrySound deleted the rollup-bundles branch June 3, 2019 07:23
@jamuhl
Copy link
Member

jamuhl commented Jun 3, 2019

not sure how they are nowadays...but in the past they were just a pain in the ass when updating dependencies.

my personal solution, which was safe in the last years of doing production stuff...fix versions - never ever use "@babel/runtime": "^7.4.5" -> dependency of dependency of dependency does no proper semver -> ends in being doomed...

this all might be better - never tested - but my experience is using "@babel/runtime": "7.4.5" is save

@TrySound
Copy link
Contributor Author

TrySound commented Jun 3, 2019

Well, there were problems with babel runtime when it was in beta. Now it's quite stable. I didn't see any problems since babel 7 release.

@jamuhl
Copy link
Member

jamuhl commented Jun 3, 2019

will check it in for now...will see...nothing to loose

@jamuhl
Copy link
Member

jamuhl commented Jun 3, 2019

published in [email protected]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants