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

Webpack support #3

Closed
paulmelnikow opened this issue Apr 30, 2016 · 4 comments
Closed

Webpack support #3

paulmelnikow opened this issue Apr 30, 2016 · 4 comments

Comments

@paulmelnikow
Copy link

paulmelnikow commented Apr 30, 2016

I've got a proof of concept of a version of this which does not depend on brfs and is also agnostic of webpack. I adapted the clever approach you took here, of patching whatwg-fetch without vendoring in the source. But instead of doing it at compile time, I did that in a build step, and checked in the result.

It's a little bit gross to check in the generated code, but I like that it's a bundler-agnostic solution. Agnosticism is a good thing. An ecosystem of opinionated packages leads to JavaScript fatigue, which is something I'm feeling pretty heavily these days.

To me, checking in a generated CommonJS module seems like a reasonable compromise for bundler agnosticism, though I'm curious your thoughts.

I need a Node + Webpack ponyfill for my current project, but I haven't found one of those – hence building this POC – and I'd rather use something that is Browserify-compatible too. My team is trying out webpack, mostly for hot loading, but hasn't really settled on it in the long term. I know there are some hot-loading solutions for Browserify now. Really, just trying to stay agnostic.

Would you be interested in taking a look at it and seeing if you'd like to incorporate it into this project? If you'd like to incorporate it here, I can avoid publishing a new project (and adding marginally to everyone else's JS fatigue). If not, I certainly have no problem publishing it separately.

@qubyte
Copy link
Owner

qubyte commented Apr 30, 2016

Hi Paul. I'm not averse to creating a standalone bundle to be built as part of an npm prepublish script. In fact that's the way I tend to lean these days. That way you can avoid checking in gross code, so long as you don't mind installing from npm. I'd be happy for a pull request!

As for Node support, I have an opinion on that, but I'll comment on your other open issue about it.

@paulmelnikow
Copy link
Author

Sounds good. I hadn't considered prepublish, in part because we have a lot of private packages which we install from git, but it totally makes sense here. I opened a PR for the Node support. Probably it makes sense to take one thing at a time. 😄

@paulmelnikow
Copy link
Author

I opened a slew of PRs for the rest of this:

@paulmelnikow
Copy link
Author

Resolved in #8!

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

No branches or pull requests

2 participants