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

allow customizable webpack configs that can specify framework/dependencies and render ingredients in any frameworks #10

Closed
elyseholladay opened this issue Oct 17, 2016 · 4 comments

Comments

@elyseholladay
Copy link
Collaborator

elyseholladay commented Oct 17, 2016

This RFC may be conflating the "allow and render ingredients in any framework" concern with the "customizable webpack configs" concern, but for the purposes of discussion, after our in-person chat on 10/27 I am making this one RFC. We can break it out into two/more when/if necessary.

Summary

A pantry should be aware of what type of framework (HBS, React, Ember, etc) its ingredients use, and the Roux ecosystem should support rendering ingredients of (m)any frameworks.

An application should be able to define its own webpack config, with any plugins and loaders it needs, and this should work for Roux as well.

Problem

Currently, we expect ingredients to have Handlebars templates and Sass. The roux-server and Béchamel cannot load ingredients in a different framework or with different dependencies. Other teams (or even other internal RetailMeNot teams) may want to write pantries with other frameworks and still use the Roux ecosystem to load and preview them.

Applications will want to define their own webpack configs and dependencies. Currently @lzilioli writes webpack configs but that is of course not scalable, especially externally. We need a way to generate webpack configs and allow apps to write their own and merge them with a default config. Pantries may want to also specify the frameworks, plugins, loaders, etc, that they need to render.

Solution Overview

In discussion with @knksmith57 he suggested that instead of using a node server (roux-server) that we instead rely on webpack to statically compile and render ingredients. This dovetails with the work to generate a webpack config for each app or pantry, as each pantry can define its own dependencies and then be rendered.

More details TBD

Questions

  • Do we care if two pantries that are used together require two different versions of a framework? Do we resolve this within Roux?
  • What webpack plugin (a few were discussed) should we use to write and merge webpack configs? @lzilioli to look into this
  • Testing still needs a server; do we repurpose roux-server or make a different testing server? @lawnsea
@elyseholladay elyseholladay changed the title Pantries should know their framework and any required helpers allow customizable webpack configs that can specify framework/dependencies and render ingredients in any frameworks Oct 28, 2016
@elyseholladay
Copy link
Collaborator Author

Here's a rough, unedited copy of my notes from talking to @knksmith57 about what next steps are:

Luke’s dynamic webpack config merge - generate webpack config necessary to build ingredient assets (template, css, js) - take the stuff the roux server does and use webpack instead

take the output of the above

run it through another build - static site generator - that builds béchamel - all the pages are the pre-rendered templates using the models

a webpack target, gulp task, etc - use the same loaders for prod apps - to statically generate a site -> takes in the generated ingredients from webpack, runs them thru the béchamel templates, spits out a site

webpack build w watch when you’re running béchamel - it triggers the change for the ONE ingredient that was changed - regenerate the static site generation for that ingredient only

for béchamel - routes that were being handled by express are now statically generated folders - the generation of the pages from the handlebars page render call is just an output of the build

page chrome partials/templates w a webpack build instead of an express app

bechamel is a static site that gets deployed every time you update it

static site also allows us to deploy versions, e.g. url-to-deployed-bechamel.io/version/1.2.4

@lzilioli
Copy link
Contributor

lzilioli commented Nov 21, 2016

it triggers the change for the ONE ingredient that was changed - regenerate the static site generation for that ingredient only

In a lot of cases, changing one ingredient is going to also impact all of the ingredients that depend on that ingredient. Either a re-render of all ingredients, or a re-rendering of all impacted ingredients would be more appropriate than just re-rendering the single ingredient that was changed directly.

@elyseholladay
Copy link
Collaborator Author

elyseholladay commented Nov 22, 2016

From discussion on 11/22 of this RFC, the following issues:

@elyseholladay
Copy link
Collaborator Author

elyseholladay commented Nov 22, 2016

Closing as we have agreed on the bulk of this RFC. Will make additional tickets/RFCs for a few follow up items incl static site gen https://github.com/RetailMeNotSandbox/bechamel/issues/16, dependency conflicts, testing #6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants