-
Notifications
You must be signed in to change notification settings - Fork 519
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
Allow for custom rollup config #234
Conversation
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.
This PR worked really well for #216, I'm able to run my app in a browser, replaces our gulp/webpack build.
@kalbasit nice, happy to hear that |
@alexeagle This PR makes it easier to use Rollup, is it something you would consider, or is there some other way being worked on or considered? |
@Globegitter can you please rebase your PR over master? It looks like one file is conflicting. |
New rollup_bundle rule lets you pass rollup.config.js. Should launch with next release |
…azel_rules_typescript_tsc_wrapped_deps//:node_modules BREAKING CHANGE: If you don't have an npm dependency on `@bazel/typescript`, you may be missing libraries like protobufjs which are required at runtime. Run `yarn add -D @bazel/typescript` or `npm install --save-dev @bazel/typescript` to fix. Closes bazel-contrib#234 PiperOrigin-RevId: 206037532
…azel_rules_typescript_tsc_wrapped_deps//:node_modules BREAKING CHANGE: If you don't have an npm dependency on `@bazel/typescript`, you may be missing libraries like protobufjs which are required at runtime. Run `yarn add -D @bazel/typescript` or `npm install --save-dev @bazel/typescript` to fix. Closes bazel-contrib#234 PiperOrigin-RevId: 206037532
Even though the default rollup setup is pretty good and should work for most use cases, I think there are also quite a few use-cases that would want to utilize further rollup plugins (us included) and having to write a custom rule for each of these separate use-cases seems a bit cumbersome. So I came up with a way of providing a custom config without having to write your own rule.
Here one would have to provide their own node_modules, which is a superset of the existing node_modules (have not found a satisfying way to have the nodejs_binary depend on two sets of node_modules). Then one would have to copy the existing
rollup.config.js
and ensure to keep theTMPL_
variables in place. It is not quite ideal but imo stil makes it easier than creating a custom rule.This would allow it to quite easily fix #216 and commonjs support mentioned in #137
Also internally we are experimenting with a few different plugins and this makes it easier for us than having to write/modify a custom rule.