We really want to avoid adding a postinstall script to axe-core - this would add it as a step that axe-core consumers run when doing npm install axe-core, which we don't want. Instead, we'll want to run the command line as a build step. This will likely mean adding a grunt task wrapping it to /build/tasks/ that you reference from Gruntfile.js.

This patch is way bigger than it needs to be; we don't need to patch the sourcemap files and we don't need to patch all of their dist variants, just the one we actually use in our build process (I'm not sure offhand which one that is, but the test should tell you when you've found it)

I don't think we should check this into the repo; if we need to test against this, we should emit it by copying from node_modules as part of the build step that patches the original

This one shouldn't need to be patched since by here CSS.supports exists and is not null due to the if statement above.

We should only need to patch one of these files (either color.js or color.cjs)

colorio.js's package.json has the following exports defined:

	"exports": {
		".": {
			"types": "./types/index.d.ts",
			"import": "./dist/color.js",
			"require": "./dist/color.cjs"

and also in the package json

	"main": "./dist/color.cjs",
	"module": "./dist/color.js",

so it seemed safer to do both, but we can pick one if we're certain only that one will be used

Our build process will only use one of them to build, so in favor of making the patch as small possible I think we should patch the one that our build grabs and leave the other alone.

Sounds good, switched to only color.js then

I'll need to repatch it when #4449 is merged

Nevermind, I rebased my branch so now it'll flow through naturally in theory. Switched patch to be for colorjs.io 0.4.3 instead.

At some point, we're going to have to stop adding tasks to Grunt if we're ever going to get rid of it.

Should now be that time?

Would be happy too, if we know what we'd rather do instead. @WilcoFiers suggested this should be in the build step. Thus there are multiple ways we could do this:

• As-is in the grunt build step
• Another custom node script like we do for several other scripts referenced in the package.json
• Tacked onto the build command in package.json with && cp path... && npx patch-package name... etc
• A different build tool, but that blows up the scope of this task

I'm of the opinion that build tools are changing all the time and it makes it feel strange to suggest just switching to the new hotness, but that just writing more custom node scripts in /build/* results in us reinventing the wheel. Still, moving towards vite/esbuild etc in the future may be my minor preference.

Since we want this to be part of the build it needs to go in the grunt build step so npm develop builds it as well. We won't be moving off grunt any time soon and not in this PR so a grunt step is fine for now.

I don't think I said it needed to be in grunt :P. We did a good while back agree not to add more grunt tasks if we could at all avoid it. It seems viable to put this work in prebuild / predevelop scripts instead. Did you try that @gaiety-deque? If that was more difficult I can live with a Grunt solution, but if we can avoid these extra dependencies + more grunt tasks I think that's the way to go on this.

Apologies @WilcoFiers I didn't mean to imply that you explicitly said it had to be in the grunt build step, just that the issue requested it be a part of the build step. Since our build step just calls "grunt" currently and the pre/post build steps were more test-like in nature it felt like we were intentionally doing these things in grunt.

Made a change 1785f2c to move it to be commands run in the package json scripts.

This file was pulled in ESLint 9.

Weird thought I fixed this but must have snuck back in through all the rebasing, fixed 87c7845

I don't think I said it needed to be in grunt :P. We did a good while back agree not to add more grunt tasks if we could at all avoid it. It seems viable to put this work in prebuild / predevelop scripts instead. Did you try that @gaiety-deque? If that was more difficult I can live with a Grunt solution, but if we can avoid these extra dependencies + more grunt tasks I think that's the way to go on this.

It seems this is missing a test. This should have failed because you're running unpatch before build. Lets confirm we actually applied the patch into axe-core by importing both axe.js and axe.min.js with window.CSS = null.

This is never going to run. npm run develop watches for changes. It never completes unless you terminate the process. And if you do that, postdevelop doesn't run.

I suspect you mean to unpatch here. I'm not sure about this unpatching at the end of the flow. It feels like there are potential gaps there, especially with develop. Might be better if we had one script that unpatches, copies, then patches, which runs before develop and build. That feels like a slightly safer way to ensure the files in patch/unpatched are always up to date.

One more thing to consider is that we could use the prepare script instead of a prebuild script. The reason we can't use postinstall is because that would trigger when someone uses npm i axe-core, but prepare only run when you call npm install in the axe-core repo. It would prevent having to run patch / unpatch over and over. @straker @dbjorge, do you see any reason not to do that?

The main gotchas I'm aware of with prepare are that:

• It runs within a package consumer if the consumer uses a "git:github.com/dequelabs/axe-core.git" dependency on axe-core rather than a more typical npm dependency
• It's not treated consistently by all packaging tools; yarn v2+ ignores it, for example.

I don't think either of those matter enough to make me want to avoid it here; the former case is already broken if it isn't running our build process, and I don't think we need optimize for the latter (so long as there's a test that would catch the patch not applying as expected).