Field Modules: build process

[jgaehring]

From #309 (comment):

As for the build process, it would be helpful to have a live farmOS server running, with fully compiled and bundled modules already installed, to properly test whether this loader will actually work with a live setup. Having a build process in place seems preferable to what I've been doing with components in the test-plugin, where I'm using template literals instead of the Vue single file components, specifically so I don't have to worry about compiling them. So I guess then I want to prioritize the build process first, but while it might make sense to work on the dev env concurrently with the build process, it's not strictly a requirement of the script loader.

So this is clearly where I want to start.

I think I'd like to approach this, if possible, by building the Webpack config from scratch, while using the current webpack.config.js files for reference. The most critical thing will be configuring the vue-loader properly.

• Start a new repo for the Weather field module
• Setup the directory structure for the repo (see Field Modules: build process #308 (comment))
• Provide a basic Webpack config based on the vue-loader Manual Setup
• Copy @paul121's template for php files

[jgaehring]

Talking with @mstenta in chat, I think we came up with a pretty good potential directory structure for a typical field module (or, specifically, a Drupal module, which can contain multiple field modules, potentially):

my_farm_module/
    - js/
        - MyFieldModule1/
            - index.js
        - MyFieldModule2/
            - index.js
    - src/
        - FieldModule/
            - MyFieldModule1/
                - js/
                    - components/
                        - MyFieldModule1.vue
                        - MyFieldModule1MenuBar.vue
                    - index.js
                    - module.config.js
                    - routes.js
                - MyFieldModule1.php
            - MyFieldModule2/
                - js/
                    - components/
                        - MyFieldModule2.vue
                        - MyFieldModule2MenuBar.vue
                    - index.js
                    - module.config.js
                    - routes.js
                - MyFieldModule2.php
    - my_farm_module.info
    - my_farm_module.info.yml
    - my_farm_module.module
    - package.json
    - webpack.config.js

In this configuration, the Drupal module will look for the necessary JS builds at /[drupal-module]/js/[field-module]/index.js. That will be the main contract between the JS side of field modules and the Drupal side, with the file paths based on machine names. Otherwise, there is flexibility in how the module author wants to lay out their directories, specifically. If they want separate build scripts for each field module, or don't want to collocate their JS with PHP, or whatever; as long as their final build product is located at that path, everything should work. That said, I like the particulars of this directory structure, and with some minor tweaks, I think it may eventually become the basis for a template repo.

[jgaehring]

When we get to #307, we may want to add a /build directory, move the webpack.config.js in there, along with an index.js as an entry point for running the dev environment, etc, etc.

[mstenta]

Had a good discussion with @jgaehring and @paul121 about the potential file structures. Attached is an example farm_eggs module with the full structure (but empty files) that we eventually got to.

farm_eggs.zip

[jgaehring]

Started a new repository here: https://github.com/jgaehring/farm_weather

[jgaehring]

Woohoo! After some struggles, I finally got the build process nailed down with jgaehring/farm_precipitation@b37b587.

I had to hammer out most of #309 in order to verify the build process produced a script that could actually be loaded successfully. There's probably more I could do, like configuring source maps, but I think we've got the critical pieces all in place that we need for now.

[jgaehring]

Oh another thing I might need to figure out for the 1.1.0 milestone is whether we'll need to add hashes to the outputted filename using Webpack's contentHash substitution. Obviously this will require changes to the build process, but because this will largely concern caching strategies, and because I've already covered some of the issues in #310 (comment), I continue to track that issue there.