The manifest.json file updates without running build

[tcmulder]

When I run npm run build, files are generated in my dist folder as I'd expect, including a manifest.json file listing the files it built with the cache-breaking suffixes added, and visiting directly (i.e. http://example.local-by-flywheel.test rather than http://localhost:3000) works great. However, as soon as I save anything with the development server running, the manifest.json file changes, breaking all the enqueues when I visit directly.

Is this the intended behavior? I would expect the dist folder to remain untouched unless npm run build gets run.

As an example, here's what's generated for npm run build:

{
  "app/assets/AkiraExpanded-Bold.woff2": "app/assets/AkiraExpanded-Bold-bd7f56b0.woff2",
  "app/assets/proximasoft-light.otf": "app/assets/proximasoft-light-f3f8ad68.otf",
  "app/assets/proximasoft-lightit.otf": "app/assets/proximasoft-lightit-d9ea599d.otf",
  "app/assets/proximasoft-semibold.otf": "app/assets/proximasoft-semibold-209b818f.otf",
  "app/assets/proximasoft-semiboldit.otf": "app/assets/proximasoft-semiboldit-c9022afb.otf",
  "common.css": "app/common-9154df4b.css",
  "common.css.map": "app/common-9154df4b.css.map",
  "common.js": "app/common-fcf2fdab.js",
  "common.js.map": "app/common-fcf2fdab.js.map",
  "editor.css": "app/editor-efd54585.css",
  "editor.css.map": "app/editor-efd54585.css.map",
  "editor.js": "app/editor-afd2bcc6.js",
  "editor.js.map": "app/editor-afd2bcc6.js.map",
  "runtime.js": "app/runtime-515840fb.js",
  "runtime.js.map": "app/runtime-515840fb.js.map",
  "theme.css": "app/theme-c3bd36df.css",
  "theme.css.map": "app/theme-c3bd36df.css.map",
  "theme.js": "app/theme-0b44574a.js",
  "theme.js.map": "app/theme-0b44574a.js.map",
  "wpackioEp": {
    "common": {
      "assets": {
        "js": [
          "app/runtime-515840fb.js",
          "app/common-fcf2fdab.js"
        ],
        "js.map": [
          "app/runtime-515840fb.js.map",
          "app/common-fcf2fdab.js.map"
        ],
        "css": [
          "app/common-9154df4b.css"
        ],
        "css.map": [
          "app/common-9154df4b.css.map"
        ]
      }
    },
    "theme": {
      "assets": {
        "js": [
          "app/runtime-515840fb.js",
          "app/theme-0b44574a.js"
        ],
        "js.map": [
          "app/runtime-515840fb.js.map",
          "app/theme-0b44574a.js.map"
        ],
        "css": [
          "app/theme-c3bd36df.css"
        ],
        "css.map": [
          "app/theme-c3bd36df.css.map"
        ]
      }
    },
    "editor": {
      "assets": {
        "js": [
          "app/runtime-515840fb.js",
          "app/editor-afd2bcc6.js"
        ],
        "js.map": [
          "app/runtime-515840fb.js.map",
          "app/editor-afd2bcc6.js.map"
        ],
        "css": [
          "app/editor-efd54585.css"
        ],
        "css.map": [
          "app/editor-efd54585.css.map"
        ]
      }
    }
  }
}

That works great and I can visit http://example.local-by-flywheel.test with functioning styling and scripts, with or without the npm run start running.

But then, if npm run start is running and I save anything that the development server is watching, the manifest.json changes to the following:

{
  "app/assets/AkiraExpanded-Bold.woff2": "app/assets/AkiraExpanded-Bold-bd7f56b0.woff2",
  "app/assets/proximasoft-light.otf": "app/assets/proximasoft-light-f3f8ad68.otf",
  "app/assets/proximasoft-lightit.otf": "app/assets/proximasoft-lightit-d9ea599d.otf",
  "app/assets/proximasoft-semibold.otf": "app/assets/proximasoft-semibold-209b818f.otf",
  "app/assets/proximasoft-semiboldit.otf": "app/assets/proximasoft-semiboldit-c9022afb.otf",
  "app/common.js.map": "app/common.js.map",
  "app/editor.js.map": "app/editor.js.map",
  "common.css": "app/common.css",
  "common.css.map": "app/common.css.map",
  "common.js": "app/common.js",
  "common.js.map": "common.425e1915187b86f54269.hot-update.js.map",
  "editor.css": "app/editor.css",
  "editor.css.map": "app/editor.css.map",
  "editor.js": "app/editor.js",
  "editor.js.map": "editor.425e1915187b86f54269.hot-update.js.map",
  "runtime.js": "app/runtime.js",
  "runtime.js.map": "app/runtime.js.map",
  "theme.css": "app/theme.css",
  "theme.css.map": "app/theme.css.map",
  "theme.js": "app/theme.js",
  "theme.js.map": "app/theme.js.map",
  "vendors~common~editor~theme.js": "app/vendors~common~editor~theme.js",
  "vendors~common~editor~theme.js.map": "app/vendors~common~editor~theme.js.map",
  "wpackioEp": {
    "common": {
      "assets": {
        "js": [
          "app/runtime.js",
          "app/vendors~common~editor~theme.js",
          "app/common.js"
        ],
        "js.map": [
          "app/runtime.js.map",
          "app/vendors~common~editor~theme.js.map",
          "app/common.js.map",
          "common.425e1915187b86f54269.hot-update.js.map"
        ],
        "css": [
          "app/common.css"
        ],
        "css.map": [
          "app/common.css.map"
        ]
      }
    },
    "theme": {
      "assets": {
        "js": [
          "app/runtime.js",
          "app/vendors~common~editor~theme.js",
          "app/theme.js"
        ],
        "js.map": [
          "app/runtime.js.map",
          "app/vendors~common~editor~theme.js.map",
          "app/theme.js.map"
        ],
        "css": [
          "app/theme.css"
        ],
        "css.map": [
          "app/theme.css.map"
        ]
      }
    },
    "editor": {
      "assets": {
        "js": [
          "app/runtime.js",
          "app/vendors~common~editor~theme.js",
          "app/editor.js"
        ],
        "js.map": [
          "app/runtime.js.map",
          "app/vendors~common~editor~theme.js.map",
          "app/editor.js.map",
          "editor.425e1915187b86f54269.hot-update.js.map"
        ],
        "css": [
          "app/editor.css"
        ],
        "css.map": [
          "app/editor.css.map"
        ]
      }
    }
  }
}

That breaks all the asset links for http://example.local-by-flywheel.test. So for instance, instead of loading common-9154df4b.css which does exist in the dist folder, it tries to load common.css instead which doesn't exist, so it 404's. Again, http://localhost:3000 works fine, but the actual site at http://example.local-by-flywheel.test is looking for the wrong files.

Why this is important to me is because I'm using wpack.io for Gutenberg development, so if I visit http://example.local-by-flywheel.test/wp-admin and try to navigate to a page to edit it, the block editor is broken since it can't find the files it's looking for unless I run npm run build every time after I save anything with the development environment. I can log into http://localhost:3000/wp-admin if I need to, but then all my URLs get entered using http://localhost:3000 instead of http://example.local-by-flywheel.test, so I need to search and replace all those in the database later.

[tcmulder]

Oh, okay, I see what's going on. Whenever you run either npm run start or npm run build, WebpackConfigHelper.js wipes the entire dist folder, re-fills it, and regenerates the manifest.json. That's necessary for the development server to work: it's looking at the new manifest.json file to grab the in-development assets rather than the in-production dist assets that were there.

Maybe this is more of a feature request then, but would it be possible to have it not do that? Could node create a different folder somewhere and the PHP API connects to it if in development mode or something? It's just really a hassle to have the entire dist folder blown away whenever I save something in development. The dist folder shouldn't be something that's used for development purposes: it should be intended for production distribution after a build only. (See for example).

[swashata]

Hi,

I don't understand why you'd want that though.

1. Manifest changes on every development or build.
2. The php package relies on the manifest for enqueuing proper assets.
3. You shouldn't save the manifest on any database. Rather you should read it directly. The php package has API for that.

If you want the whole output to be saved somewhere except the dist directory, then change the option in wpackio.project.js file.

[swashata]

Also, I will write some docs on how we can use wpackio for Gutenberg blocks. We are successfully using it in our team.

[tcmulder]

Gutenberg docs would be helpful! I have it set up and working well for my blocks already, but it'd be excellent to see a more official setup for achieving that.

So, maybe I'm using the tool incorrectly and you could help me understand a better approach. I suppose my question tl;dr is, what URL do you use when you're adding content (especially images) within wp-admin?

How do you develop and then use blocks with the script paths always changing? I don't think it's good to access wp-admin through the IP address wpack.io gives me, because any images I upload for instance get saved like http://192.168.0.233:3000/wp-content/uploads/2021/06/example.jpg and only work while npm run start is running the wpack.io server. If my IP address changes, or a coworker does some work on the site over a different IP address, we'll end up with a bunch of broken image links that are using a variety of IP addresses all throughout the database. Those are still there when the wepback.io server isn't running: they're saved to the database as if it's running and aren't reachable if it's not.

Normally, I just access the site through whatever URL I set up through Docker or Local or MAMP, so every URL saved to the database is exactly the same and work without wpack.io running a development server (so http://example.test/wp-content/uploads/2021/06/example.jpg, with all URLs being under http://example.test). All my wp-admin work is done using that URL, so all URLs in the database are consistent and are easy to find and replace later for launch. My coworkers can use that same URL and not need to worry about what my IP address was the last time I was adding content.

However, right now, I can run the build, start entering content at http://example.test/wp-admin, notice I'd like some title's color to be blue instead of red or what have you, and as soon as I save that stylesheet, http://example.test/wp-admin reports all my wpack.io scripts as 404'ing and all my blocks as not being registered as a result. I'd much prefer http://example.test to keep working with the incorrect blue colored headings and wait for me to choose to run a build at the time I choose to, rather than having any development changes cause every block I've created to stop working.

Normally, running a development build should not cause any prior production build to stop working. I do a lot of Gatsby development: gatsby develop runs the development sever, but never touches the "dist" folder so the production code continues to work just fine; only when I run gatsby build does it update the "dist" folder. "Dist" is only used for distribution, i.e. production, and builds are triggered when the site's ready to go to production, not every save in development with most build tools I've used.

Is that making sense?

[swashata]

Well you are right about that. But at this moment, I do not have the mileage to work on this change, as it sounds like a major thing. Among internal things, we have to somehow inform Wpackio\Enqueue about which directory to use dist or dev. And it has to be WordPress compliant. We cannot read some environment or arbitrary files to determine that.

But if you think you can come up with a solution, I will gladly review your PR and merge.

[tcmulder]

Okay thanks, I'll see if I can get some time to look into it once my current project is nearing finish.