How do YOU perform local development? Tips wanted

Product Discussions
, ,
1

This is how we’re currently setup:

  1. I run the docker command to clone my environment
  2. dotcli instance to the remote instance i just cloned
  3. dotcli pull to get the files locally in a better folder structure
  4. dotcli instance to switch to my local instance
  5. dotcli push -w to push changes i’m making to vtl and js files “live”
  6. Refresh the dotCMS page in my browser to view my changes
    I make changes and when I’m finished I commit them. Currently, we’re manually keeping our remote in sync with GitHub, but I’ll setup GitHub actions to do this soon.

Pros:

  • This lets me have the entire instance run locally. This is vital since it lets me use the IDE tools and snippets we’ve already created
  • “migration” seems as easy as dotcli config ing another remote instance and dotcli pushing

Cons:

  • dotcli push -w 1 seems to be the fastest “sync” i can get, and sometimes i refresh to see my changes before it’s finished pushing
  • /files directory also contains images, videos, and other media used on the site. We can use git lfs for those or just ignore them

This largely supports the direction given in this article.

Is there anything I’m making more difficult for myself? Anybody have something drastically different?

2

Hi, one thing that I do while coding is to make dotcli watch only the file or folder I’m working on, so the sync is quicker.

Maybe we can add to dotcli a watch with glob patterns?

1 Like
3

Hi!

If you already have a GitHub repo with the files, configuring the GitHub action integration can make the work easier for you.

Nolly!

4

Thanks Nolly, it’s in the plans!

I make changes and when I’m finished I commit them. Currently, we’re manually keeping our remote in sync with GitHub, but I’ll setup GitHub actions to do this soon.

I’m curious what other “hot tips” people have

5

I’ve seen other cli tools watch for changes in the files directly, instead of polling. Is that something that was explored?

6

Watching a folder was explored but I believe using watching, at least as it worked in our CLI, caused file locking issues on Windows boxes. We fell back to a polling mechanism which works out of the box cross platform and has decent performance even with large directories.

7

Interesting. Thanks for the info!

After thinking a bit more I wondered if a dotcli sync would be a nice addition. Sometimes, in the moment it’s easy to use the web ui to make a quick change and see the results. I’m often finding I forget to pull the contents back from the running instance into my local environment. I need all the help I can get saving me from myself :sweat_smile:

8

Hello,

If you’re using Vite’s dev server, referencing JS, TS, styles, etc using Vite’s backend integration, there’s a plugin for Vite called vite-plugin-full-reload. this allows you to auto-refresh on any glob (eg: src/**/{*.vtl|*.vm}. We use this on VTL files to auto refresh the page we’re working on.

You’ll can also set a custom delay for however long it takes for the file(s) to upload to dotcms.