Wait for dom-ready about injection HOT 10 CLOSED

or acutely, do you mind to move this pacakge into our shiny mono repo

That would make it less discoverable. github-injection is not related to OctoLinker in any way (other than being from the same developers). If you move it in there it's essentially gone for me.

Just go ahead with package.json

The JS file has a check for exports, meaning that it supports globals when loading it directly in the browser. Adding a require would kill that.

from injection.

Hmm, I'm still undecided, so I think we should just leave it in this repo for now.

Either that or we just assume that these days most project are using a bundler anyway. Maybe a bit harsh, I'm undecided.

I'm personally ok with this. Worst case, someone complains and we can add a build process then.

I think it's acceptable to drop bower support these days

I also agree with this, it's not worth supporting bower.

from injection.

That's a good idea! Would you like to create a PR for this?

from injection.

How do you handle dependencies? Inline dom-loaded?

from injection.

Just go ahead with package.json and ignore bower. I think it's acceptable to drop bower support these days

from injection.

or acutely, do you mind to move this pacakge into our shiny monorepo https://github.com/OctoLinker/OctoLinker/tree/master/packages? Should be an easy task.

from injection.

That would make it less discoverable. github-injection is not related to OctoLinker in any way (other than being from the same developers). If you move it in there it's essentially gone for me.

Good point, if we're going to move this into the monorepo (which would make octolinker development a little easier), we should start publishing those packages.

The JS file has a check for exports, meaning that it supports globals when loading it directly in the browser. Adding a require would kill that.

If we want to preserve this use case, we could add a build process and publish bundled code.

from injection.

Exactly, the idea is to publish everything to npm in OctoLinker/OctoLinker/tree/master/packages. Until now there was no need since all packages are used by us only. As soon as github-inject is in there we have to start publishing.

If we want to preserve this use case, we could add a build process and publish bundled code.

Either that or we just assume that these days most project are using a bundler anyway. Maybe a bit harsh, I'm undecided.

from injection.

Exactly, the idea is to publish everything to npm

That misses the point, I can't star github-injection if it's part of a monorepo. This is sort of ok when it's babel and its plugins, but less ok when it's something unrelated.

from injection.

Now I get you point. That's indeed an issue and maybe I was overthinking the monorepo a bit. I know that some companies have a single repo for all there products / services. They argue that this way you can do global refactoring across different modules quite easily. I think I was driven by this idea.

With a monorepo we would also mess up PRs and Issues. Maybe this doesn't work for OSS that way.

@josephfrazier what's your thoughts on this?

from injection.