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

framework/base sync #28

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

framework/base sync #28

wants to merge 1 commit into from

Conversation

woodseowl
Copy link
Contributor

This is a functional proof of concept that we could use a composer script to make the process of keeping cwd_base in sync with cwd_framework updates. They would still be managed as separate repositories.

Notes:

  • I made a very simple assumption: you have a directory next to cwd_base that is the checkout of cwd_framework.
  • I thought it best to have the css directory be locally built, so it doesn't bring those compiled assets with it.
  • This same approach could be used for other derivative projects.

@woodseowl woodseowl requested a review from ama39 July 1, 2020 19:29
@alisonjo315
Copy link
Collaborator

@woodseowl How do you use it -- is it a composer command you run from your local copy of cwd_base, or? I haven't used "scripts" in composer other than like, those hook/triggered things associated with install/create-project/update/require operations, like...

        "post-update-cmd": [
            "@update-framework"
        ],

(I'm sure there are other ways to make use of the scripts section of composer.json, I just don't know them :) )

@woodseowl
Copy link
Contributor Author

Composer scripts are straight forward:

composer update-framework

But make sure you see assumption #1: "you have a directory next to cwd_base that is the checkout of cwd_framework"

If I got the concept right and this works for @ama39, I'll write it up more. For now, I figure it doesn't hurt to have it in composer.json?

@ama39
Copy link
Collaborator

ama39 commented Aug 11, 2020

Thank you for this. I updated the cwd_framework repo today, and am about to try this script out for the first time. Looking through the commands, I think some of them will need minor tweaks. I'll follow-up with those changes after I verify, but I suspect the following changes will be needed:

  1. project.scss should be omitted. It goes to the cwd_project theme instead.
  2. The cwd*.js wildcard will pick up some non-production files that shouldn't be in cwd_base (e.g., cwd_experimental.js and cwd_tables.js which are both just experimental). Though now that I look, I'm seeing that cwd_experimental.js actually is in cwd_base currently, just not loaded in the libraries file. Either it snuck in at some point or I left it in as an "undocumented feature." I guess that's fine, but I do think cwd_tables.js should be left out. The table of contents functionality in cwd_experimental.js is fully functional (it's just not well-tested). Whereas cwd_tables.js is unfinished functionality, which I wouldn't want anyone to think they can use.

@ama39
Copy link
Collaborator

ama39 commented Aug 11, 2020

The script worked nicely. Thank you again! I did find more tweaks that are needed:

  1. The sass/components directory should be omitted. Like project.scss, these files are meant for the cwd_project theme (which becomes the theme for a particular project).
  2. The sass file cwd_patterns.scss should be omitted. It's something new I'm working on that is just part of the base framework documentation.
  3. There are some jQuery-related JavaScript files that should be omitted. They are there so the Framework has them locally, but we stopped including them in the Drupal theme a while ago to avoid conflicts with Drupal's own jQuery serving. The three that were added by the script were:

jquery-ui-1.10.2.custom.min.js (no longer used in our Drupal themes)
jquery-ui-easing.min.js (no longer used in our Drupal themes)
jquery.ba-throttle-debounce.min.js (this does get used by projects sometimes, but is not needed by the base theme)

So overall, it's looking like things are working well with this script, but that there are a number of file exceptions that make the logic messier to cover. Does the syntax for those recursive copy commands include something for defining exceptions? It might be smoother to define exceptions than to have to specify all the exact files to copy.

Copy link
Collaborator

@ama39 ama39 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change requests were noted in my two comments.

@woodseowl
Copy link
Contributor Author

Wow, my last comment was July 10, 2020 -- that was maybe 4 days before I got sequestered to Daily Check?

I'm sorry this didn't progress further. And, for what it's worth, I'm always happy to have someone else pick up something like this and move it forward (perhaps on another branch + PR so it's easy to see).

I don't know when I will be able to work on this, so please try to carry it forward if you want to!

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

Successfully merging this pull request may close these issues.

3 participants