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

[WIP] Setup rollup #75

Merged
merged 2 commits into from
Nov 3, 2019
Merged

[WIP] Setup rollup #75

merged 2 commits into from
Nov 3, 2019

Conversation

faergeek
Copy link
Contributor

@faergeek faergeek commented Oct 9, 2019

It started at #14 a long time ago.

I added a really basic setup of rollup. All that is done right now is just replacing hand-written IIFE with the one that rollup adds. Exports are still manual. Should I continue at this point or something doesn't look right already? I probably should add non-phony make target for simple-markdown.js. Is it correct?

@ariabuckles
Copy link
Owner

This looks ok to me—I'd like to replace the custom umd export at the end with an export default SimpleMarkdown and let rollup do it's thing there.

I think we should add a make target as you say. I'm open to migrating to npm scripts in the future, but would like to do that all at once when we do. Unfortunately I believe the make target may have to be phony because I've had issues with non-phony targets and timestamps not being updated by some git operations. I'm probably missing something here, but thankfully phony targets aren't very expensive for a small project like this.

Adds some integration for rollup/the rollup changes with some other
parts of the build system:

 * `make` targets
 * fixes typescript config
 * uses es6 module exports to switch to fully using rollup's umd
 * integrates rollup with npm prepublish so I can't forget to build
@ariabuckles
Copy link
Owner

Added some integrations with make & npm prepublish, and switched to es6 exports so we can use all of rollup's umd instead of my homegrown one; thanks! (37a72f1)

I have some ideas for where this could go that might be useful if you're interested! Or if you have ideas, I'm interested in hearing or seeing them!

That said, I want to make sure that with any infrastructure changes we:

  1. keep meeting the product use-cases (flow & typescript support, easy to include in webpack, node, or raw html, etc.)
  2. are getting actionable benefits from the new system.

If we could eventually support es6 named exports for tree shaking like you suggested in #55, I think that would be really neat and match the above criteria. I'm not totally sure how to ensure that typescript and flow play well with both versions, but it's probably doable. You probably have other ideas as well :).

@ariabuckles ariabuckles merged commit bbbe5bf into ariabuckles:master Nov 3, 2019
@faergeek faergeek deleted the rollup branch November 4, 2019 05:13
@faergeek
Copy link
Contributor Author

faergeek commented Nov 4, 2019

Awesome 👍

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