-
Notifications
You must be signed in to change notification settings - Fork 34
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
Legacy browser support, better Monorepo usage #39
Legacy browser support, better Monorepo usage #39
Conversation
- Replace non-standard `jsnext:main` with proposed `module` prop - Use `index.js` for all `module` values - Use `dist` files for all `main` values
Awesome! Looking forward to digging into this — will dig into it and comment this week. Thanks @caseyWebb ! |
This is excellent. There's a lot of much needed cleanup in here. I was thinking of moving the tko In general, The I think we can remove The tests are written for Jasmine version 1.3, which is incompatible with Jasmine 2.0. Jasmine 1.3 will be here for a long time; we use mocha+chai+sinon for some of the newer packages. What's the difference between The tests (
Are you experiencing this too? Did you have thoughts on fixing them? This is a pretty hefty commit but it's the way to go, so I'm ok merging this and fixing up anything it breaks, unless there's something that stands out as needing attention before that should happen. Thanks @caseyWebb — This is a much needed and valuable patch! |
A +1 on git-lfs. I actually ran into an issue cloning the repo because I have an ssh alias for github which git-lfs couldn't resolve, and had to change the remote from As far as Most of the tests pass for me, but there are still some errors. I'll have to double check to see what the errors are, but I don't believe it's those. To be honest, I'd really like to see a migration to jest instead of mocha if migrating the tests is a goal. It's extremely fast, and based on jasmine already. There is definitely a lot going on in here. I began with trying to restrict changes to just the build, but revamping the lerna usage made that a whole lot easier and less overall code, so it seemed the right way to go. AFAIK, there is nothing that needs to be done before merging this. |
Awesome, thanks for the comment @caseyWebb Let's set up new issues and reference them:
Just a quick merge & comment right now; I'm hoping to set aside some time for this soon, but feel free to get started with the issues. |
This is a first, although pretty comprehensive, pass at refactoring the monorepo that...
Idiomatic Lerna
The built browser bundle has been moved into the
packages
directory. Instead of usingrollup-plugin-includepaths
, packages are linked viapackage.json => dependencies
(anddevDependencies
for test-only imports), whichlerna bootstrap
then does its magic on.lerna bootstrap
has been registered as a postinstall hook at the root level, so installing deps and linking packages across the entire repo can be done with ayarn install
in the root.Legacy Browser Support
Instead of Babel, the TypeScript compiler is used with the
allowJs
option and a target ofES3
. It's faster, compiles down lower than babel (afaik, babel only supports ES5), and will allow for incremental adoption of TypeScript if desired.Multiple Builds
The browser bundle has 4 builds available: ES3, ES6, ES3+Minification, ES6+Minification.
Individual modules do not have minified builds, because they can only be consumed via JS bundlers and minification should be done last for best results (not to mention debugability).
Modular Usage
TKO modules are passed through rollup, but other TKO modules are marked as external to prevent a bunch of duplication and are output in ES2015 module format and thus only supported with modern JS bundlers. Rolling them up renders faster builds for consumers wish to use individual modules, and allows transpilation without bloating the build process. Theoretically, we could create AMD/SystemJS bundles as well for script tag usage, but if you're going through the hassle of optimizing for weight, you're probably using ES2015 modules — at least you should be, IMHO of course.
The combined bundle on the other hand uses UMD format for universal consumption. AFAIK, tree-shaking won't take effect even if this is output in ES2015 module format without some refactoring, so this seems most reasonable for the moment.
Documentation for modular usage is very much needed. Currently the only way I could get it working was copying
packages/tko/src/index.js
to my own project and removing the parts I don't need.Tests
Jasmine was upgraded to an incompatible version at some point. This has been rolled back, so now the test failures are actual failures.