2017 Todos: Help Wanted

[ghost]

This thread might be a good place to list some of the issues that contributors new and old can jump in and help with. Everybody who has been added as a member of this org should be able to manage issues, push code to github, publish packages to npm, and add new members. If you would like access, please ask any existing member!

There is quite a backlog of issues on the repos. Mostly this is my fault as I haven't had the time or inclination to go into these lately.

Sometime soon node will start to work with ES modules not behind a flag. When that happens, we will need to figure out how to best support these new npm packages authored in the new format.

We have some work to do playing catch-up with HMR and bundle splitting, improving these modules (among some others) and building new modules:

• https://github.com/AgentME/browserify-hmr
• https://github.com/browserify/factor-bundle

There's been some good work done on that front in the choo community with https://github.com/choojs/bankai

Some of the compatibility modules could use some work, such as https://github.com/hughsk/ify-loader which makes it possible to seamlessly use browserify transforms from nested package.json in webpack.

There's a fantastic community built around a transform for webgl shaders that could use help and more glsl packages: https://github.com/stackgl/glslify

The backlog for budo could also use some help: https://github.com/mattdesl/budo/issues

I think there's a lot of opportunity to make perf gains throughout the pipeline. Maybe on-disk caching?

The handbook has a backlog of issues and needs some new sections for newer tools and some of the older tools can be removed. https://github.com/browserify/browserify-handbook

There's always room for more documentation. If you make or find something cool you can add it to https://github.com/browserify/awesome-browserify

If you know of any other tasks in the browserify ecosystem that could use some help, please chime in!

[max-mapper]

There are issues and PRs on the Browserify website that could use triage help https://github.com/browserify/browserify-website. Let me or @substack know if you want to become a maintainer there to help. But note that we don't really want to revamp the website, we just want help keeping it up to date and accurate. (E.g. don't open a PR rewriting it or adding a bunch of new complexity without buy in from other maintainers).

[ghost]

There's been some work lately in the community building better tree shaking tools.

indutny created https://github.com/indutny/common-shake
and goto-bus-stop created https://github.com/goto-bus-stop/common-shakeify
to wrap common-shake as a browserify transform. These new tools could use more documentation, tutorials, bug hunts, and charts to compare with tools in other ecosystems.

[bcomnes]

@substack / anyone who has a clue whats going on, would you be interested in doing a call or hangout at some point to discuss the state of things?

[ghost]

wzrd.in is a CDN providing browserify standalone bundles for npm packages. There are lots of issues in the tracker and some sysadmin work that needs to be done.

[trygve-lie]

For ES modules, it might be of value to keep an eye on https://github.com/standard-things/esm.

That is moving much faster than native ES modules in node and will probably be a usable thing pretty soon.

[hughsk]

@substack I'd be happy to move ify-loader into this org if that's helpful :)

[fpereira1]

@substack @maxogden I am interested in picking up some triaging in the browserify-website as mentioned. I am keen to become a maintainer there to help. Any issue in particular that I could look at first?

[ghost]

@hughsk if you think it would help, go for it! I don't want to tell other people what to do and everybody can make up their own mind about where to put their projects, but I do think it could be helpful to move packages into this org so that many people are empowered to merge changes and publish new releases. That way people can better follow their individual initiatives rather than waiting on human bottlenecks too much. I personally don't like being that bottleneck.

[max-mapper]

@fpereira1 woot! I'd start by checking out and merging browserify/browserify-website#45, i'll add you as a maintainer. Any commits to gh-pages will deploy the site automatically.

[hughsk]

@substack sweet — I feel very much the same way re: bottlenecks :) Done! ✨

[ghost]

@hughsk can you please run this command?

npm access grant read-write browserify:developers ify-loader

I'm putting together an administrative document to show what to do in order to add repos and new members.

[hughsk]

@substack Sure thing! Sounds good :)

[ghost]

I documented the procedures for adding new members and projects at https://github.com/browserify/admin

[ungoldman]

Some very low-hanging fruit for a first time contributor would be updating the links to reflect the new org & repo addresses across the many repos that are now housed here.

[gregtatum]

I'm interested in lexing and parsing work lately. Any issues people could point me to that need fixing?

[yoshuawuyts]

From work on bankai I've been able to build up some experience with working on browserify and its ecosystem. This is my take on cool things that might use work.

---

For watchify it'd be cool if we could move off chokidar/fs-events and onto recursive-watch which has no native dependencies. It'd also be neat if we could save the intermediate state to disk, so that rebooting watchify will be immensely sped up.

Probably the largest unsolved problem in the ecosystem is asynchronous module loading / splitting files into multiple small files. factor-bundle allows extracting shared code between bundles. The bundles then rely on being loaded in the right order. partition-bundle is similar, but allows bundles to be loaded with a loadJS() function.

I'm not overly convinced Hot Module Reloading in is a great idea. The abstraction seems leaky, and it seems people are starting to move away from it. Reloading CSS still seems to be done though, which makes sense to me.

It seems people have recently started creating more sourcemap related tooling. For example zeit/next creates an overlay when the source fails to be parsed. This also seems to be a big part of recent marketing around create-react-app.

I think browserify is in a pretty good place already, but here's another few fun things that could probably be experimented with:

• A transform to hoist modules into the global scope, removing the overhead to make require() work in the browser.
• wasm2js as a template string, with corresponding transform. I think it'd be cool if we could write inline WASM using template strings. Also a fun challenge to make the transform performant ✨

edit: Also https://github.com/hughsk/disc has been immensely helpful over the years. More work on analysis / visual tools would be grand!

[bcomnes]

Regarding hmr/live-reloading... whatever budo does, I like that.

[Widdershin]

For what it's worth, budo works well with browserify-hmr. budo -- -p browserify-hmr.

The nice part of a composable ecosystem, I'm pretty sure it wasn't designed to work like that, but it works well.

[goto-bus-stop]

A transform to hoist modules into the global scope, removing the overhead to make require() work in the browser.

I have been working on a plugin like that over at https://github.com/goto-bus-stop/browser-pack-flat. It works in most situations now (including circular dependencies) but it's turned into a bit of a mess internally haha. It could use some eyes and refactoring now. Would be sweet to have some more people try it out anyway!

[fpereira1]

@maxogden I reviewed and merged browserify/browserify-website#45
closed: browserify/browserify-website#33 and browserify/browserify-website#24

I went through a few open issues, there seems to be a theme of people posting browserify questions to the website repo, see this browserify/browserify-website#51 that I have closed

[cezaraugusto]

hey all, this lib helped me on several occasions and I'd like to help back. I can help with governance, updating docs, bug triaging, and helping @fpereira1 in website stuff

[IonicaBizau]

I'd like to help too! I am not sure how much time I will be able to invest, but I can help with responding to issues and doing code review from time to time.

Keep up the great work! 🚀

[stevemao]

I have merged a few PRs in this org. Could someone publish browserify-handbook to npm? I'm happy to do it myself if I'm added on npm. thanks!

[balupton]

Migrated this stale issue from #5 to https://github.com/orgs/browserify/discussions/22. No action required