{"action":"created","issue":{"url":"https://api.github.com/repos/ractivejs/ractive/issues/2271","labels_url":"https://api.github.com/repos/ractivejs/ractive/issues/2271/labels{/name}","comments_url":"https://api.github.com/repos/ractivejs/ractive/issues/2271/comments","events_url":"https://api.github.com/repos/ractivejs/ractive/issues/2271/events","html_url":"https://github.com/ractivejs/ractive/issues/2271","id":116339706,"number":2271,"title":"RFC: Plugins monorepo","user":{"login":"Rich-Harris","id":1162160,"avatar_url":"https://avatars.githubusercontent.com/u/1162160?v=3","gravatar_id":"","url":"https://api.github.com/users/Rich-Harris","html_url":"https://github.com/Rich-Harris","followers_url":"https://api.github.com/users/Rich-Harris/followers","following_url":"https://api.github.com/users/Rich-Harris/following{/other_user}","gists_url":"https://api.github.com/users/Rich-Harris/gists{/gist_id}","starred_url":"https://api.github.com/users/Rich-Harris/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Rich-Harris/subscriptions","organizations_url":"https://api.github.com/users/Rich-Harris/orgs","repos_url":"https://api.github.com/users/Rich-Harris/repos","events_url":"https://api.github.com/users/Rich-Harris/events{/privacy}","received_events_url":"https://api.github.com/users/Rich-Harris/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-11-11T13:56:24Z","updated_at":"2015-11-11T22:04:37Z","closed_at":null,"body":"Plugins are something of a ghetto at the moment. Clicking [Plugins](http://docs.ractivejs.org/latest/plugins) in the nav of any ractivejs.org page takes you to a page on docs.ractivejs.org (with the Docs tab highlighted), containing a bunch of links, many of which are to out-of-date pages (I've been pretty dreadful at keeping the 'official' ones up-to-date).\r\n\r\nOn top of that, the process for creating plugins is unnecessarily confusing and inconsistent and out-of-date (hello, unmaintained Grunt template).\r\n\r\n## Solution: a monorepo\r\n\r\nSpecifically, [this monorepo](https://github.com/ractivejs/ractive-plugins). There are a few clear advantages:\r\n\r\n* We can automate lots of drudge work – building dist files, generating high-quality package.json files, etc\r\n* Much easier to maintain consistency of code style and so forth\r\n* Creating new plugins is as simple as creating a new folder and cribbing from similar plugins. No awkward project setup. Everyone gets ES6 out of the box\r\n* Discoverability is much better – for plugin users, plugin developers (easier to avoid duplication of effort), Ractive developers (at the moment it's hard to keep track of which plugins are in the wild)\r\n* When plugin APIs change (which is inevitable, e.g. we'll probably need to overhaul the adaptor and transition APIs at some point) it's much easier to update plugins en masse\r\n* Easier to have a coherent testing strategy\r\n* It'll make it much easier to generate a plugins.ractivejs.org site, with (for example) automatically generated installation instructions and demos for each plugin\r\n\r\n## Downsides\r\n\r\n* Some loss of flexibility – if a plugin needed a very specific build process, we'd have to accommodate that somehow\r\n* Third party plugin authors would need to dance to our tune if they wanted to be in the official plugin repo (maybe not a bad thing though – easier to ensure quality across the ecosystem)\r\n* The repo *could* get huge, eventually\r\n\r\n\r\nLots still to do but I thought I'd put this out there to gauge initial reactions. Let me know your thoughts"},"comment":{"url":"https://api.github.com/repos/ractivejs/ractive/issues/comments/155923972","html_url":"https://github.com/ractivejs/ractive/issues/2271#issuecomment-155923972","issue_url":"https://api.github.com/repos/ractivejs/ractive/issues/2271","id":155923972,"user":{"login":"JonDum","id":191920,"avatar_url":"https://avatars.githubusercontent.com/u/191920?v=3","gravatar_id":"","url":"https://api.github.com/users/JonDum","html_url":"https://github.com/JonDum","followers_url":"https://api.github.com/users/JonDum/followers","following_url":"https://api.github.com/users/JonDum/following{/other_user}","gists_url":"https://api.github.com/users/JonDum/gists{/gist_id}","starred_url":"https://api.github.com/users/JonDum/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/JonDum/subscriptions","organizations_url":"https://api.github.com/users/JonDum/orgs","repos_url":"https://api.github.com/users/JonDum/repos","events_url":"https://api.github.com/users/JonDum/events{/privacy}","received_events_url":"https://api.github.com/users/JonDum/received_events","type":"User","site_admin":false},"created_at":"2015-11-11T22:04:37Z","updated_at":"2015-11-11T22:04:37Z","body":"\r\n> As far as I can tell, the main reason people care about tags is so that they can get dist files for a specific commit...Frankly, people using GitHub as a package manager (i.e. Bower users) are doing it wrong – GitHub isn't a place to store dist files.\r\n\r\nYes and no. I'd say it's more so that you know with relative confidence which commit is the one published to npm for that version. That's why running `npm version minor` automatically bumps the `version` in the `package.json` **and** makes a new commit for you with that change and a subsequent tag of the new version (so unless you're rewriting history with `rebase -i`, the developer can't mess this up). Say I want to checkout an old version of something as it was at `v0.2.1` on npm to apply a patch and test something—I would just need to run `git checkout tags/v0.2.1`. With everything in one repo, we definitely lose that without a bunch of workarounds.\r\n\r\n> I think component packages should contain a) the component file itself (vanilla JS and CSS only, though the source could conceivably use preprocessors and/or linked files),\r\n\r\nAnd the template(s)? For those rare few of us who use runtime.js.\r\n\r\n> I'd rather have a clusterfuck of issues in one repo than a clusterfuck of issues across a clusterfuck of repos\r\n\r\nSounds good for core team. What's the work flow for us non-core people? Hundreds of PRs?\r\n\r\nIf it's easier for you guys to have the plugins *you* maintain all in a single repo, then by all means. No complaints about that, should definitely go ahead and merge them all in. I'm not sure I'm comfortable with the workflow/tools yet for the stuff that my team uses across a bunch of projects.\r\n\r\n---- \r\n\r\nPS\r\n\r\n> Also, I just created a Grunt plugin and it was 38Mb! Sharing the bulky devDependencies between plugins results in a much nicer time, I believe.\r\n\r\nAdd `link=true` to your `~/.npmrc`. Then everything is symlinked :)"}}