Continuous building changes have been deployed

Unknown
Unknown
edited September 2018 in Dev & Ops

Since the change now runs our builds on our data servers deploys may take a little bit longer now. Generally the build takes 10-20 seconds depending on how much has changed since the last deploy. If you notice any issues while deploying please notify me and ops.

What is being built?

Right now this is primarily Rich Editor, but will affect more and more parts of Vanilla as time goes on. This affects all of knowledge base as well.

What changed?

Built files used to live in directly in git. Previously in /js/webpack directories. This caused a lot of pain with merge conflicts.

These build files now live in git ignored /dist directory. This means if all you do is git clone https//github.com/vanilla/vanilla Rich Editor, Knowledge Base, and in the future of pages will not be functional. Server based API endpoints will still work, but the pages themselves will not have the javascript files they need to execute.

Required build step

The build step has been required, but could have been done by someone else before you and checked into git. You now need to build your own local copy.

A composer post-install step has been added that will run this build for you. So when doing composer install these files will get generated. This same step runs on our infrastructure as well, which is how our production sites get these files.

New dependencies

This means running a source version of Vanilla will require

  • yarn
  • node

To stay consistent with our infrastructure and CI setups node 10.x and yarn 1.9.x are recommended.

https://docs.vanillaforums.com/developer/tools/building-frontend/

This documentation page provides some information about the build, but if you just have the dependencies installed (yarn and node, installation instructions in the doc), then everything after will be run for you after a composer install

Comments

  • Vanilla Forums
    Vanilla Forums

    Will the new build automatically happen when the next release is forked from master?

    Will the state correctly revert to non-building if we rollback a server from master to release/2.7?

  • Unknown
    Unknown
    edited September 2018

    Yes and yes. I've tested both on infrastructure before deploying.

  • Unknown
    Unknown

    Open source forum post https://open.vanillaforums.com/discussion/36708/the-git-version-of-vanilla-no-longer-ships-pre-built-fronted-assets#latest

  • Unknown
    Unknown

    I was going through the docs and thinking through some scenarios and it seems like we are going to have to be passing enabled plugins to the client. Consider this scenario:

    • A plugin's javascript is now automatically compiled into the build, regardless of whether or not the plugin is available.
    • So I make sure to dynamically load my plugin's javascript from its entry point.
    • I'll need to know whether or not the plugin is enabled in order load its javascript and do its thing.

    In the past we've tried to avoid letting the client know all enabled add-ons or even the version of Vanilla as a security layer. Perhaps we should have just a convention on how an add-on transmits its enabled status to the client? On the other-hand having core visibility would reduce a bit of boilerplate.

    Always a game of trade-offs.

  • Unknown
    Unknown
    edited September 2018

    Each addon build it's own bundle.

    image.png

    This is the current outputted files for the forum.

    Rich Editor not enabled? the forum/addons/rich-editor bundle will not be loaded. As a result the `async~mountEditor` dynamic chunk will not be loaded either (dynamically imported from the rich-editor bundle).

    Here's an example from the knowledge section with multiple dynamic pages:

    image.png

    In this case the Editor file is still dynamically imported, except through i the page editor. We're using the editor as a library instead of as a plugin so the plugin has no affect on editor components loading.

Categories