`${framwork}` support
mini-eggs opened this issue · comments
Would this package accept PRs with support for @pwa/preset-${framework}? I see you have two open issues for other larger frameworks but I'm thinking slightly smaller ones. HyperApp, Elm, Aurelia and so on.
Hey, thanks! I want a controlled subset of presets, but will soon open it up for community-driven presets and plugins.
Official presets will be maintained in this repo and will be included in the pwa init selection list, whereas community-driven packages won't. It's tricky because there are (probably) hundreds of JS frameworks with active users, but I can't "officially" support them all. The configuration is pretty easy/straight-forward, but scaffolding out templates and ensuring compatibility with other "official" packages can get out of hand quickly.
As for community-driven packages, I still haven't fully decided how to handle that. The easiest thing to do would be to auto-inject pwa-plugin-* and pwa-preset-* packages (in addition to / after @pwa/* packages), but as you can imagine, there may be cross-community-package conflicts and/or order-specific packages.
Because of this, I might have to add a presets and plugins key on pwa.config.js that attaches the community packages in a desired order. This would feel very Babel-esque and not foreign... I think.
In addition to Angular and Polymer, I think I want to offer support for a Web Component framework. I haven't added a ticket yet because am still undecided, but SkateJS or Stencil might be good, unique additions.
Hey, sounds like a good idea w/r/t quality. No beef there.
Because of this, I might have to add a presets and plugins key on pwa.config.js that attaches the community packages in a desired order. This would feel very Babel-esque and not foreign... I think.
I like this. Might be nice to include some babel like features in the CLI as well. Something along the lines of $ pwa init --presets=preset-1,preset-2 --plugins=plugin-1 to generate that initial pwa.config.js.
Cool 👍
Maaaybe. My initial gut reaction is that I don't really like that. I'd imagine a community-driven-user will just hit "None" preset, configure the rest, and then manually install & attach the add-ons they want.
I'd think that a free-for-all init field (to type in preset & plugin names) isn't that helpful. And adding some kind of HTTP request that prefills a multiselect still poses the issue of ordering. 😬
Luckily, there's time to figure this out! haha
My thoughts may change, who knows~
Hit me if they do! Happy to help implement. I know I would def use that beef'd up init command.