[core] Support release:build with cmd.exe

[michaldudak]

Makes building @mui/icons-material (and, therefore, running yarn release:build in the repository root) succeed on Windows.

[mui-pr-bot]

Details of bundle changes

@material-ui/core: parsed: +Infinity% , gzip: +Infinity%
@material-ui/lab: parsed: +Infinity% , gzip: +Infinity%
@material-ui/styles: parsed: +Infinity% , gzip: +Infinity%
@material-ui/private-theming: parsed: +Infinity% , gzip: +Infinity%
@material-ui/system: parsed: +Infinity% , gzip: +Infinity%
@material-ui/unstyled: parsed: +Infinity% , gzip: +Infinity%
@material-ui/utils: parsed: +Infinity% , gzip: +Infinity%

Generated by 🚫 dangerJS against f9fbcae

[eps1lon]

what's this?

[michaldudak]

A utility that lets run cp (and few other *nix tools) on Windows.

[eps1lon]

on Windows.

Could you be a bit more specific about your environment? Both in the git-bash and PowerShell this task is fine. We specifically test dev scripts for Windows + PowerShell.

There's a limit to the environment matrix we can support. So if you're using the ancient windows command prompt or some exotic Windows build then you may want to consider using a more standard development setup.

[mnajdova]

I remember this failed on the default CMD, but I am using Git Bash and haven't had problems with that one.

[eps1lon]

I remember this failed on the default CMD

Yeah, we gain more value by you switching over from that tool than fixing every compat issue with CMD. cmd.exe is effectively deprecated since 2008 and GitHub also defaults to PowerShell now.

I definitely get behind general OS support at our scale. But support of every tool is a bit of a stretch. And I do have issues as well since I us a non-standard shell as well. But when I do have these issues I switch to standard tools instead of spending time on (and bloating) the codebase to fix these.

[michaldudak]

I'm using Powershell 7.1.4, so it's hardly an ancient tool.

However, yarn does not. Yarn uses the default command interpreter, which, even on the latest Windows, happens to be cmd. I'm not aiming to support every tool there is, just the ones that are default, so that developers can use standard tooling to build the library.

[eps1lon]

I'm using Powershell 7.1.4, so it's hardly an ancient tool.

I did not say that PowerShell is an ancient tool.

so that developers can use standard tooling to build the library.

Outdated versions of PowerShell are not standard tooling.

Leaving this discussion as this is again an instance where Michal fails to engage with the argument. If you want that everything is tailored to your liking while simultaneously making no effort to apply the same standard to everybody else, then so be it. But I don't have to put up with it anymore.

I have no idea what yarn has to do with it. I'm not aware that yarn implements cp -r.

[michaldudak]

I did not say that PowerShell is an ancient tool.

I never suggested you did. I'm just saying I'm using an up-to-date toolset.

Outdated versions of PowerShell are not standard tooling

Yes, in general, that's undeniably true.
However, what outdated version do you have in mind in the context of this conversation? As I said I'm using the latest PowerShell and it fails to build.

I have no idea what yarn has to do with it

Then let me explain: If you are on Windows, yarn uses the default command interpreter to run commands defined in the scripts section of package.json. So even if I'm using PowerShell to execute yarn build in /packages/mui-icons-material, yarn will use cmd.exe to run cp -r lib/ build/. And this fails.

If you want that everything is tailored to your liking while simultaneously making no effort to apply the same standard to everybody else, then so be it.

Does my solution break anything to anyone else? Does it make it harder to build on other systems? If so, please let me know, and I'll consider something else or drop this completely. As of now, my understanding is that it improves the developer experience on Windows by allowing to use any of the standard, built-in shells to build the project.

[mnajdova]

My understanding is that it improves the developer experience on Windows by allowing to use any of the standard, built-in shells to build the project.

I agree with this. And looks like we are not loosing anything with this change. So I don’t see any downside with adding this.

[mnajdova]

@michaldudak I just noticed that the base is wrong, we should target master. Please update and feel free to merge afterwards

[michaldudak]

Good point, thanks!