phpgt / build Goto Github PK

It's now standard that all PHP.Gt repos pass phpstan's level 6 analysis. Currently there are many areas where typing can be improved, etc.

Requires writing to build.cache - could specify where to put it as argument.

.es7 files to be handled by default.

If there is an SCSS syntax error the error is shown in the terminal but then doesn't continue building until restarted.

Currently the script fails if there isn't already a www directory. This isn't great for DX.

Now I've switched to the symlink option by default for directories like asset or data, if there are a lot of operations on that directory, it triggers the build again. It would be useful to specify build tasks that are only one-off, to be ran once on a --watch process.

Something like...

{
  "data/**/*": {
    "require": {
      "vendor/bin/sync": ">=1.3.0"
    },
    "execute": {
      "command": "vendor/bin/sync",
      "arguments": ["./asset", "./www/asset", "--symlink"]
    },
    "options": {
       "run-once": true
    }
  }
}

"run-once": true or "repeat": "once". Something like that.

By default the src/style and src/script directories have a build requirement, using scss and babel to create www/style and www/script, but what about basic static content?

Static content could be placed directly into www, but it might be worth treating that directory as a special directory. Having some generated files in there and some source files feels kind of messy.

The default that WebEngine v2 has been using is treating the src/asset directory as a source of static assets. No scss compilation in here! A nice default could be to provide a wildcard match on the asset directory's children and perform a straight copy to www.

There is currently no mechanism for not pumping the files through a third party program. Copy is such a common requirement that even if the asset default isn't used, it will be worth implementing.

Currently rsync is a requirement of having any static files, and setting up rsync on Windows is not trivial. Basic directory syncing can be achieved in PHP.

Example syntax (note the prefix will be trimmed from the relative file path):

{
	"src/asset/**/*.*": {
		"execute": {
			"sync": {
				"prefix": "src/asset",
				"destination": "www/asset"
			}
		}
	},
	"src/style/**/*.scss": {
		"requires": {
			"sass": "^3.5"
		},
		"execute": {
			"command": "sass",
			"arguments": "src/style/main.scss www/style.css"
		}
	},
	"src/style/**/*.js": {
		"requires": {
			"node": "^9.2",
			"babel": "^6.0"
		},
		"execute": {
			"command": "babel",
			"arguments": "src/style/main.js www/script.js"
		}
	}
}

Save the SCSS file, CSS compiled, browser reloads! Nice. (Or... it would be.)

1. I don't think I've ever used the "require" block feature of the build.json
2. Writing the command out as a comma separated list of arguments is tedious.

Backwards-compatible improvement:

build.ini

[script/**/*.es6]
require=node *,babel *,webpack *
execute=./node_modules/.bin/esbuild script/script.es6 --bundle --sourcemap --outfile=www/script.js --loader:.es6=js --target=chrome105,firefox105,edge105,safari15

[style/**/*.scss]
require=sass 1.6.*
execute=sass ./style/style.scss ./www/style.css

Then we can continue the default behaviour of build.ini, build.production.ini.

Then there's a new issue for WebEngine to determine what the environment is by which config file is present (config.production.ini = production = load build.production.ini).

Dependabot needs to be tamed, as per PhpGt/WebEngine#568

Currently the build script processes the input/output itself, but this should be handled by php.gt/cli

md5_file is obviously more costly than checking the filemtime, but there are issues with mounted directories' filemtimes in Vagrant for Mac (at least).

Check to see if there is a way to use filemtime to trigger a new build across the different virtualisation platforms.

I would like to minify and drop the source maps when in production (minification using esbuild reduces 80% of the bundled size!)

Currently this has to be a manual step, but I'd like to define the build in the project's build.json.

.js files are meant to be synced without being compiled. A file at script/example.js syncs to www/script/example.js, but a file at script/vendor/example.js does not - it just creates the vendor directory. Easy to test against.

As noticed in PhpGt/Sync#13, tasks are currently executed per matching glob, rather than once for any matching globs. This leads to inefficiencies but mainly strange output on commands that provide feedback.

The empty string is not a known stream, so this throws an exception.

For newcomers, who probably haven't installed webpack, scss, etc. when the build command fails with a message such as Gt\Daemon\CommandNotFoundException: webpack, it should link to the documentation showing how to install.

My build times were getting slow on a large project (~10 seconds per build!)

esbuilder reduced the 10 seconds to 17 milliseconds. Seems fair to use this instead.

Something super useful to have is a symlinked directory within www. This allows user uploads to non-www directories, or mounted drives to be served publically.

EDIT: This functionality is now live, but this issue is being kept open while it is documented.

Does this work? Needs testing.

It would be useful on certain build steps to have more than one command in the execute block, ran one after another.

Can we change the execute block to be an object OR an array of objects?

Not sure why, but when running build, it takes a lot longer to complete the process than running the command itself. In particular, the sass compilation takes a lot longer through the build runner.

Needs investigating.

Composer uses the terminology "require" for its dependencies.

Needs to be documented enough to be linked in to the intro document on php.gt

A feature of the Build system is to be able to get started coding without any need for build systems; it's currently possible to build a working WebEngine application without any SCSS/ES6 files, without even knowing about php.gt/build

The idea is that until a filetype that requires building is used, the developer won't need to be bothered about the build runner, but as soon as they do use a filetype that requires building, they should be able to save it and the build runner will kick in automatically.

This works fine currently, but it is an all-or-nothing approach. As soon as you use a .scss file in the default location, the build system kicks in, but complains if you don't also have babel, etc. installed -- even if you're not using babel.

1. Make standard Cli namespace, as with other repos.
2. Move to streamed output.
3. Fix the description of the runner command.

There are too many problems running inotify within Docker environments, so polling will be used.

• Find topmost directory of each build section (src/script/**/*.js becomes src/script)
• Poll the directory's contents using something like tar c $directory | md5sum
• Only md5 matching globs otherwise images within style directories might take some time!

Tested this on 100MB of static assets and it takes 0.2s to poll. Not bad for worst case scenario.

This error message was confusing me while working on an older project.

It turns out, the problem was that I hadn't performed npm install, and a file wasn't present that was expected to run.

I think this error message is incredibly confusing. If this error message appears, is it always because the dependent binary/script isn't available? If so, the error message should be worded accordingly:

Error: The required command can not be found (./node_modules/.bin/something)

Bring it up to the modern standard.